UIkit 2.0, bitcoinprices.js

16 Dec 2013 | By Alex Young | Comments | Tags ui libraries bitcoin

UIKit

UIKit 2.0

UIKit 2.0 (GitHub: uikit / uikit, License: MIT) is a frontend framework that provides components for layout, navigation, and more complex UI widgets like dropdown replacements. It uses jQuery and FontAwesome. Version 2 has just been released, which has some new features including a Markdown editor that supports syntax highlighting and an extensible toolbar.

There’s extensive documentation and a theme tool, so you can have a look at the main features quite easily.

bitcoinprices.js

bitcoinprices.js (GitHub: miohtama / bitcoin-prices, License: MIT) by Mikko Ohtamaa is a client-side library for fetching Bitcoin prices. It supports currency selection, and uses BitcoinAverage as the price API.

BitcoinAverage itself is an open source Python project that monitors multiple exchanges for prices:

Price is a weighted average. Meaning that for every exchange the last trade price and last 24h trading volume is taken, each exchange contributes to the final price only to the extent of it’s current trading volume. For a more detailed arithmetics explanation check here.

It’s got a nice and simple Bootstrap-based website with graphs and tables.

Vim.js

13 Dec 2013 | By Alex Young | Comments | Tags vim emscripten editors
Surely the very reason Emscripten was created?

Finally, my worlds have collided! In case you didn’t know, I regularly write a Vim blog. It’s surprisingly easy to find things to say about this 22 year old text editor, and it’s been my main tool for writing code and articles for a long time. Vim.js (GitHub: coolwanglu / vim.js) by Lu Wang is an Emscripten port of Vim, allowing you to use Vim in a browser.

It runs pretty well on my computer – it seems fast, and the commands I typically use work. It’s not like these Vim layers for IDEs and other editors that miss certain motions, registers, and so on: it’s basically Vim. Split windows and tabs work, but the help files aren’t available (or I can’t find them). The way it works in the browser is to use a <span> for each terminal character, which means for the 43x115 example window there are 4945 spans!

From a JavaScript point of view, I found the Sync to Async Transformation document interesting. The author is trying to figure out how to deal with JavaScript’s asynchronous nature, given that Vim expects to have a non-busy synchronous sleep() function:

Most works are automatically done by web/transform.js, read the comments inside for more detail. But there are a few left, mainly function pointers, which cannot be automatically identified. Whenever vim.js crashes and you see callback function is not specified! in the browser console, congratulations, you have found one more async function at large.

I wonder if there are any Node developers or ES6 experts that can help with this? If you’re interested in the project, there’s a TODO which has some Emscripten issues and client-side work that needs doing.

JavaScript Developer Survey 2013: Results

12 Dec 2013 | By Alex Young | Comments | Tags community surveys

The JavaScript Developer Survey has now closed. As always the results are available to the community for further analysis:

Most people write client-side code.

51% of readers write client-side code, while 28% said they write server-side code. Last year client-side was at 98%, so I imagine this is partly due to a changing audience on DailyJS, but it’s interesting how strong server-side development is becoming.

Where do you write JavaScript? 54% said “at work”, and 45% said “side projects”. This is probably a case of people doing both – I find it’s common for programmers to be both hobbyists and professionals.

The majority of readers have been writing JavaScript for three to five years (34%). I can’t help but feel this is thanks to the growth of Node – people rediscovering JavaScript after using other languages for server-side web development, or the growth of client-side frameworks like AngularJS and Backbone.js. I can’t imagine doing design without some JavaScript skills.

78% of readers said they don’t use a language that compiles to JavaScript. I’ve noticed some of the influential members of the Node community are vocal about these languages, so it seems like our readers agree. I try to keep some coverage of these languages on the blog, but in general the focus is on JavaScript.

CoffeeScript was the most popular “compile-to” language (64%), and TypeScript was up from last year to 19%.

The style question caused much confusion. Semicolons, commas at the end, and methods with one space were popular options. It’s interesting to see 9% using tabs and 11% using spaces. Unlike some languages, JavaScript can survive a little bit of variance in tab size, so I’m not too bothered either way. Client-side veterans seem to use four spaces, though, and 8% of respondents selected this option.

The results for testing amused me:

  • Yes: 25%
  • No: 26%
  • Sometimes / Not enough / Not too much / When needed: 50%

I like your honesty. “Not enough” could be just modesty, so I’m going to read this as “a lot of readers write tests but think they could be doing better”.

Jasmine is hugely popular, with 30%. I still think tap is the best approach, but it only received 2% of your clicks. Mocha’s doing well with 27%, and QUnit is down to 16%. I think this is more evidence of a large number of Node developers doing the survey, but it could also be the fact that people see Mocha as a browser/Node module, and QUnit as something just for jQuery (which it isn’t really).

CI servers? 36% said yes. Node is definitely CI server friendly – I’ve recently been setting up a TeamCity server for Objective-C projects and it’s surprisingly hard work. Compared to switching on Travis CI for an open source Node project it’s a joke. However, Jenkins is the most popular CI server (44%), and TeamCity got 13%, so perhaps people find it easy to slot client-side or Node tests into an existing CI server in companies that use multiple languages.

AMD is extremely popular.

It turns out people like AMD! However, if we break down the stats for CommonJS, we see 17% using CommonJS and 12% using Browserify. For a long time I advocated CommonJS, but substack’s Browserify argument is convincing…

Grunt is winning at build scripts (60%). Fortunately, “npm scripts” had a good response (17%), which is encouraging because I feel like lots of tasks are simple enough to work that way, rather than needing a confusing 200 line Gruntfile.

I was surprised to see AngularJS and Backbone.js both get 25% for client-side frameworks. They have mindshare, but I can’t help but feel they solve very different problems.

The common wisdom seems to be IE support should start at IE 8 (37%). I’m going to guess that’s to support corporates, which has been the bane of my web development existence for over a decade now.

Do you use ES6 features? 85% said “No”, so you’re OK if you don’t. I probably only do to write DailyJS articles, but we’ll see this start to grow over the next year.

PHP is the most popular primary development language (24%), and C# got 17%. Hello .Net folks!

Thanks to everyone who took part in the survey! If you can use the data for something cool, I’d love to hear about it.

Node Roundup: parse5, redis-timeseries, request-as-curl

11 Dec 2013 | By Alex Young | Comments | Tags node modules curl html parsing redis statistics

parse5

parse5 (GitHub: inikulin / parse5, License: MIT, npm: parse5) by Ivan Nikulin is a new HTML5 parser, based on the WhatWG HTML5 standard. It was built for a commercial project called TestCafé, when the authors found other HTML5 parsers to be too slow or inaccurate.

It’s used like this:

var Parser = require('parse5').Parser;
var parser = new Parser();
var document = parser.parse('<!DOCTYPE html><html><head></head><body>Hi there!</body></html>')
var fragment = parser.parseFragment('<title>Parse5 is &#102;&#117;&#99;&#107;ing awesome!</title><h1>42</h1>');

I had a look at the source, and it doesn’t look like it was made with a parser generator. It has a preprocessor, tokenizer, and special UTF-8 handling. There are no dependencies, other than nodeunit for testing. The tests were derived from html5lib, and include over 8000 test cases.

If you wanted to use it, you’ll probably need to write a “tree adapter”. Ivan has included an example tree adapter, which reminds me of writing SAX parser callbacks.

Ivan also sent in mods, which is a module system designed to need less boilerplate than AMD-style libraries.

Redis Time Series

Tony Sokhon sent in redis-timeseries (GitHub: tonyskn / node-redis-timeseries, License: MIT, npm: redis-timeseries), a project for managing time series data. I’ve used Redis a few times as a data sink for projects that need realtime statistics, and I always found it worked well for the modest amounts of data my projects generated. This project gives things a bit more structure – you can create instances of time series and then record hits, then query them later.

A time series has a granularity, so you can store statistics at whatever resolution you require: ts.getHits('your_stats_key', '1second', ts.minutes(3), callback). This module is used by Tony’s dashboard project, which can be used to make a realtime dashboard.

request-as-curl

request-as-curl (GitHub: azproduction / node-request-as-curl, License: BSD, npm: request-as-curl) by Mikhail Davydov serialises options for http.ClientRequest into an equivalent curl command. It also works for Express.

// http.ClientRequest:
var req = request('http://google.com/', {method: 'POST', json: data}, function (error, response, expected) {
  curlify(req.req, data);
  // curl 'http://google.com' -H 'accept: application/json' -H 'content-type: application/json' -H 'connection: keep-alive' --data '{"data":"data"}' --compressed
});

// Express:

app.get('/', function (req) {
  curlify(req);
  // curl 'http://localhost/pewpew' -H 'x-real-ip: 127.0.0.1' -H etc...
});

I imagine Mikhail has been using this so he can replicate requests based on logs to aid in debugging.

Feathers, Angular Snap.js, File-size.js

10 Dec 2013 | By Alex Young | Comments | Tags frameworks libraries modules node angularjs

Feathers

Feathers (GitHub: feathersjs / feathers, License: MIT, npm: feathers), sent in by Matthew Phillips, is an Express-based web framework for creating RESTful services that use Socket.IO.

Because it’s based on Express, you can use existing Connect middleware. That means you could drop in an authentication module like everyauth, and your preferred client-side framework (like Backbone.js or AngularJS), and then use the Feathers conventions for CRUD-style server-side code and Socket.IO events.

Matthew wrote a glowing email about it – he’s been using it for client project. I had a look at the source, and it’s actually pretty lightweight: it’s basically based around events that bridge between Express routes and Socket.IO.

The main author, David Luecke, has built it with Rubberduck and Uberproto, two of his other modules. Uberproto is basically inheritance sugar, and Rubberduck allows methods to be wrapped with events.

Angular Snap.js

Angular Snap.js (GitHub: jtrussell / angular-snap.js, License: MIT) by Justin Russell is a Snap.js directive for AngularJS. Snap.js makes mobile-style “shelf” layouts a lot easier, and is intuitive to use – touch gestures work as expected, and click-dragging the mouse opens the drawer as well.

The directive can be used as an attribute, or event an element:

<div snap-drawer>
  <p>I'm a drawer! I maybe I've got some sweet navigation links.</p>
</div>

<snap-drawer>
  <p>I'm a drawer! I maybe I've got some sweet navigation links.</p>
</snap-drawer>

File-size.js

File-size.js (GitHub: Nijikokun / file-size, License: MIT, npm: file-size) by Nijiko Yonskai is a module for generating human-readable file sizes. For example, filesize(186457865).to('MB') returns 177.82.

It supports various specifications, including JEDEC and IEC, and it works in browsers and Node.

Lazy Module Declaration, Mozilla Funds Hoodie

09 Dec 2013 | By Alex Young | Comments | Tags frameworks libraries

Lazy Module Declaration

LMD

Lazy Module Declaration (GitHub: azproduction / lmd, License: MIT), or LMD, is a module “assembler”. Modules are written with CommonJS, then you add a JSON file that describes the build process. This file can be generated by the lmd command-line tool. The command-line tool can selectively include client-side specific functionality, so you can do things like build with IE optimisations.

It can also load CSS, and has Node integration. Interestingly, require seems to be decorated rather than overloaded:

require() is not overloaded:

  • require.css() for css
  • require.js() for js (non LMD-modules)
  • require.async() for async LMD-modules (objects, strings, modules)

The main contributor (Mikhail Davydov) works at Yandex, and is writing some interesting features for it. For example, there’s a screenshot of a Mac-style GUI tool for LMD that looks impressive.

Mozilla Funds Hoodie

I wrote about Hoodie a few weeks ago, and the project recently had some good news: Mozilla donated $25,000.

Team Hoodie is proud to announce that Mozilla is supporting Hoodie with a $25,000 donation. Mozilla has interest in Hoodie with their Appmaker initiative. The donation will ensure that Hoodie development will commence faster and some early goals are support for Persona authentication in Hoodie, as well as a Docker-based “Hoodie as a Service” setup. In the spirit of both Mozilla and Hoodie, all this work will be available as Open Source software.

That’s encouraging because there are many projects similar to Hoodie vying for wider adoption, so this seems like a much needed feather in Hoodie’s cap.

Notch and WebGL, npm_lazy

06 Dec 2013 | By Alex Young | Comments | Tags webgl npm games node

Notch, WebGL, Dart

Brandon Jones wrote a summary of Notch’s WebGL and-Dart related activity: Notch, WebGL, Dart, and ramping up quickly:

I can’t tell you how many time I see hobby developers saying ”I’m building a game!” and what they actually have to show for it is a really complicated system for loading meshes and shaders. It’s all well and good to think about long term goals and engine structure and such, but if you’re going to build a game then please build a freaking game! Don’t build an engine that you will someday build a game on top of, because you will never get past step one.

Dart seems to appeal to Notch, maybe because of his Java background. It’s cool seeing his work come together on Twitter, from the initial ideas to working code with screenshots.

npm_lazy

Sometimes npm goes down (which is why you should donate to npm). But there’s a solution: mirror it! If you’re too lazy to mirror the whole thing, how about just caching the modules you need to deploy your projects? That’s where npm_lazy by Mikito Takada comes in.

This is a local cache for npm. It has a configuration file that allows you to tailor it to your needs – you can set the cache lifespan, HTTP timeout, and so on. Once you’ve set that up, you can run it as a server. Then you just use npm --registry to set the server as your npm registry.

It has some caching logic – anything that isn’t local will be fetched, and metadata is updated when a module is requested the first time after a restart.

Multiprocess Firefox

05 Dec 2013 | By Alex Young | Comments | Tags firefox browsers

Multiprocess Firefox

I know a lot of DailyJS readers who use Chrome and Safari as their main browsers, partly due to iOS and Android’s popularity, and partly because Chrome’s initial performance gains enticed them away from Firefox. The big issue over the last few years has been the fact browsers are switching to using multiple processes, the idea being that resources can be shared better and fallout from crashes can be mitigated.

If Firefox isn’t your main browser, you probably use it for testing or just try it out every few months to see what’s been going on. The thing most of us have been looking for is Chrome (and apparently IE)-style multi-process support. Bill McCloskey has written a post about this very topic: Multiprocess Firefox. Bill is a programmer at Mozilla, and you may remember his post about incremental GC in Firefox.

Although the work so far sounds promising, there are some major technical hurdles. These partly relate to the nature of how JavaScript interacts with the DOM, and how Firefox handles add-ons:

JavaScript execution and layout happen on the main thread, and they block the event loop. Running these components on a separate thread is difficult because they access data, like the DOM, that are not thread-safe. As an alternative, we’ve considered allowing the event loop to run in the middle of JavaScript execution, but doing so would break a lot of assumptions made by other parts of Firefox (not to mention add-ons).

Like the threaded approach, Firefox is able to run its event loop while JavaScript and layout are running in a content process. But unlike threading, the UI code has no access to content DOM or other content data structures, so there is no need for locking or thread-safety. The downside, of course, is that any code in the Firefox UI process that needs to access content data must do so explicitly through message passing.

You might not realise it, but Firefox itself uses a lot of JavaScript:

Content scripts. IPDL takes care of passing messages in C++, but much of Firefox is actually written in JavaScript. Instead of using IPDL directly, JavaScript code relies on the message manager to communicate between processes.

We decided to do the message passing in JavaScript instead, since it’s easier and faster to prototype things there. Rather than change every docshell-using accessor to test if we’re using multiprocess browsing, we decided to create a new XBL binding that applies only to remote <browser> elements. It is called remote-browser.xml, and it extends the existing browser.xml binding.

If you’re an add-on author, you’ll be pleased to hear add-ons are being taken seriously. However, Mozilla may need your help in the future:

We realize that add-ons are extremely important to Firefox users, and we have no intention of abandoning or disrupting add-ons. At the same time, we feel strongly that users will appreciate the security and responsiveness benefits of multiprocess Firefox, so we’re willing to work very hard to get add-ons on board. We’re very interested in working with add-on developers to ensure that their add-ons work well in multiprocess Firefox.

It’s hard to imagine Firefox OS not using multiple processes, and Bill mentions this early on in the post:

Firefox OS relies heavily on the multiprocessing and IPC code introduced during Electrolysis.

Electrolysis was a project to use multiple processes, but the focus was tighter than changing the desktop browser. Firefox’s layout engine, Gecko, supports multiple threads, and the “Gecko platform” supports multiple processes. But, as the Electrolysis wiki page points out, the Firefox frontend does not currently use multiple processes.

Will we see a browser share increase when Firefox is updated to support multiple processes? I don’t know, but as a front-end developer I’m excited about seeing this feature released sooner rather than later.

Node Roundup: Ben Noordhuis, Node.app, Infect.js

04 Dec 2013 | By Alex Young | Comments | Tags node modules objective-c di

Ben Noordhuis

Every time I write about a new Node release, I notice how much work Ben Noordhuis has done. He’s been an important contributor to Node and libuv, and has always seemed patient and polite on the mailing list.

Ben Noordhuis decided to leave Node and libuv. If you’re not familiar with his work, take a look at the Node ChangeLog – Ben’s commits go back to summer 2010. Ben will be missed!

Node.app

Node.app

Node.app (GitHub: node-app / Interpreter, License: MIT) is a project to bring Node’s API to JavaScriptCore. The aim is a drop-in replacement that’s compatible with Node’s master branch, and to reuse the JavaScript in Node’s lib/ directory (the core modules).

It needs the latest iOS or Mac OS X, and if you check out the source you’ll need to get the submodules (git submodule update --init --recursive).

The list of currently working modules includes partial fs support, util, url, events, path, stream, querystring, and assert. The process object is also supported.

I’ve only had a brief look at the source in node-app / Nodelike, but it looks like they’re writing Objective-C to add the necessary libuv bindings. This is the code you’ll find in src/ in joyent / node.

Infect.js

Infect.js (GitHub: amwmedia / infect.js, License: MIT, npm: infect) by Andrew Worcester is a dependency injection module. It’s not specifically for Node, but I was intrigued by the idea of bringing AngularJS-style DI to Node projects.

Registering a dependency. A simple call to infect.set() with the name you want to use, and the mutable object you’d like to register will do the trick. In the example below we are using a function, but you can register any type of mutable value (Functions, Arrays, Objects, etc).

infect.set('Logger', function(str) {
  // prepend a time to every log line
  console.log((new Date()).toLocaleTimeString() + ' ==> ' + str);
});

It supports function injection (infect.func) and class injection (infect.func with a constructor function). Andrew has included jsFiddle examples in the readme, so you can play around with the code.

AngularJS D3 Charts, Yo three.js, TinyCore.js

03 Dec 2013 | By Alex Young | Comments | Tags libraries webgl architecture graphics yeoman

AngularJS D3 Charts

Chinmay sent in Angular-charts (GitHub: chinmaymk / angular-charts, License: MIT, bower: angular-charts), a set of AngularJS directives for graphs that use D3. To use it, include angular-charts.min.js and then inject the dependency with angular.module('yourApp', ['angularCharts']).

Configuration options for graphs can be included using directives, or passed as options in JavaScript. There are also events for mouseover, mouseout, and click. The charts have animations, tooltips, and the values will be adapted to the graph’s size as necessary.

A Yeoman Generator for three.js

If you’re looking for a friendly way to get started with three.js, then Timmy Willison’s Yeoman generator (GitHub: timmywil / generator-threejs, License: MIT, npm: generator-threejs) may be what you’re looking for.

The template it outputs renders a red cube, and it includes the usual Yeoman stuff like a Grunt build script and a web server for development.

TinyCore.js

TinyCore.js (GitHub: mawrkus / tinycore, License: MIT) by Marc Mignonsin is a library for organising projects around modules:

We use dependency injection to provide the modules the tools they need to perform their job. Instead of having a single sandbox object with a lot of methods, a module defines explicitly the tools it needs. The mediator, that provides a way of communication for the modules, is one of the default tools that has already been implemented (located in the “tools/mediator” folder).

Modules have an extensible, event-based API. There’s also a factory class, called “Toolbox”:

In order to provide the modules the tools they need to perform their job, TinyCore uses a tools factory, TinyCore.Toolbox. A tool can be registered at any time for later use. Whenever a module is instantiated, the tools specified in the module definition will be requested and injected as parameters of the creator function.

TinyCore is written with testing in mind, and has an extension for Jasmine.

connect-cache-manifest, pushnot

02 Dec 2013 | By Alex Young | Comments | Tags express node apps

connect-cache-manifest

connect-cache-manifest (GitHub: dai-shi / connect-cache-manifest, License: BSD, npm: connect-cache-manifest) by Daishi Kato is Express middleware for generating a HTML5 cache manifest file. Manifests basically list the files needed by the application when it’s offline, so any essential client-side assets can be cached by the browser.

Daishi’s middleware takes an object and then generates a suitable manifest file. It can recurse through directories so including lists of JavaScript, CSS, and images is easier.

app.use(cacheManifest({
  manifestPath: '/application.manifest',
  files: [{
    file: __dirname + '/public/js/foo.js',
    path: '/js/foo.js'
  }, {
    dir: __dirname + '/public/css',
    prefix: '/css/'
  }, {
    dir: __dirname + '/views',
    prefix: '/html/',
    ignore: function(x) { return /\.bak$/.test(x); },
    replace: function(x) { return x.replace(/\.jade$/, '.html'); }
  }],
  networks: ['*'],
  fallbacks: []
}));

pushnot

pushnot

pushnot (GitHub: dtinth / pushnot, License: MIT) by Thai Pangsakulyanont is a push notification server based on ØMQ, Express, and Zephyros. It supports notification encryption and can be hooked up to Growl.

Pushnot consists of three major components: The server that clients can send a notification to, and subscribers can subscribe to these notifications. The client is any application that wants to send a notification to the user. The subscriber waits for the server to push the notification and notifys the user.

It’s got an interesting mix of technologies, if you’re looking for an Express application that uses pub/sub, and it has a command-line interface as well.

List.js, _part_

29 Nov 2013 | By Alex Young | Comments | Tags libraries functional

List.js

List.js

Version 1.0 of List.js (GitHub: javve / list.js, Bower: javve/list.js, License: MIT) by Jonny Strömberg has been released. It’s a small library for making tables searchable, sortable, and filterable. It also works on unordered lists and divs, and supports templating so you can style it fairly easily. It doesn’t have any dependencies, and the API is straightforward JavaScript:

listObj.add({ name: 'Jonny', city: 'Stockholm' });

listObj.add([
  { name: 'Gustaf', city: 'Sundsvall' }
, { name: 'Jonas', city: 'Berlin' }
]);

There are also plugins for List.js. The project includes tests and can be installed with Bower or Component.

The _part_ Library

_part_ (GitHub: AutoSponge / part, License: MIT) by Paul Grenier is a small library for making native methods available as partially applied functions.

In part, you use typical OO functions (like the ones in native prototypes) to create two functional counterparts, “left-part” and “right-part”, which partially apply the receiver or parameters respectively.

While I was reading about this library I noticed the author has several other interesting posts on his blog:

JavaScript Developer Survey 2013

28 Nov 2013 | By Alex Young | Comments | Tags community surveys

Here is the JavaScript Developer Survey for 2013! You have two weeks from now to complete the survey (the 12th of December).

I asked for help with the questions last week, and the response was incredible! I really appreciate the suggestions, and I’ve made a list of the pull requests that I accepted. Any that weren’t accepted were either due to a clash with another suggestion, or lack of time on my part.

Scale npm

27 Nov 2013 | By Alex Young | Comments | Tags node modules npm

Scalenpm

The official Node blog has a post about issues scaling npm: Keeping The npm Registry Awesome. It explains some of the recent downtime and outlines plans to improve the situation.

The root cause of these downtime was insufficient resources: both hardware and human. This is a full post-mortem where we will be look at how npmjs.org works, what went wrong, how we changed the previous architecture of The npm Registry to fix it, as well next steps we are taking to prevent this from happening again.

The post is relatively lengthy and buried at the end is a plea for funding:

But we need your help! All of these necessary improvements require more servers, more time from Nodejitsu staff and an overall increase to what we spend maintaining the public npm registry as a free service for the Node.js community.

Please take a minute now to donate at https://scalenpm.org!

By burying the funding plea at the end the author was presumably trying to avoid making the post sound spammy, but seeing as most people don’t read anything on the Internet I thought I’d reiterate the point because I’m not scared of sounding spammy: DONATE TO NPM! SAVE FERRIS!

If you pledge $75 you’ll get benefits, like $25 credit on Nodejitsu or Iriscouch. Sounds good to me!

GitHub Avatar Chrome Extension, AMDClean

26 Nov 2013 | By Alex Young | Comments | Tags jquery chrome amd build

GitHub Avatar Chrome Extension

GitHub Avatar Chrome Extension

Writing Firefox add-ons or Chrome extensions can be off-putting for those of us who are good at JavaScript but not so great at browser plugin APIs. Anas Nakawa sent in chrome-github-avatars (GitHub: anasnakawa / chrome-github-avatars, License: MIT) which is a Chrome extension for displaying GitHub avatars on the news feed page.

It might seem like a modest extension, but the reason I liked it was he used a Yeoman generator. Anas’ project includes all the stuff I’m familiar with, like Bower and jQuery, but also things that I’m not too familiar with, like Chrome’s manifest.json. It seems cool that you can use tools popular in the JavaScript community to create browser plugins.

AMDClean

AMDClean (GitHub: gfranko / amdclean, License: MIT) by Greg Franko is a build tool for converting AMD code into standard JavaScript that works with RequireJS’s optimiser.

By incorporating amdclean.js into the build process, there is no need for Require or Almond.

Since AMDclean rewrites your source code into standard JavaScript, it is a great fit for JavaScript library authors who want a tiny download in one file after using the RequireJS Optimizer.

So, you get great code cleanliness with AMD, reduced file sizes, improved code readability, and easy integration with other developers who may not use AMD.

Greg notes that it also supports Grunt, so it should be easy to drop into your existing projects.

ResponsiveComments, jQuery Evergreen

25 Nov 2013 | By Alex Young | Comments | Tags responsive design jquery es6

ResponsiveComments

ResponsiveComments (GitHub: chambaz / ResponsiveComments, License: MIT) by Adam Chambers is designed to support conditional loading using HTML comments:

Through the use of HTML comments, markup can be introduced to progressively enhance an experience as various media queries or feature detections evaluate to true.

Data attributes are used with valid media queries to conditionally display HTML. For example:

<div data-responsive-comment-media="(min-width: 769px)">
  <!-- <div><p>Any content can go in here</p></div> -->
</div>

IE 9 and below support requires the matchMedia.js polyfill, but otherwise browser support is pretty good.

jQuery Evergreen

What would jQuery look like if it was written for modern browsers with ES6 modules? jQuery Evergreen (GitHub: webpro / jquery-evergreen, License: MIT, Bower: jquery-evergreen) by Lars Kappert is an attempt at answering that question.

jQuery Evergreen works with modern browsers. It has the same familiar API as jQuery, and is lean and mean with the following, optional modules: selector, class, DOM, event, attr and html. The source is written in the ES6 Modules format, and transpiled to an AMD version, and a “browser global” version using the ES6 Module Transpiler.

It’ll work with current versions of most browsers thanks to transpilation and an IE9 polyfill for classList.

You can even create custom builds with Grunt, like this:

grunt --exclude=attr,class,dom,event,html,mode,selector

WegGL Hobbit, Zombies, Debugging and Profiling Tools

22 Nov 2013 | By Alex Young | Comments | Tags games webgl

WegGL Hobbit, Zombies

There’s a Chrome Experiment called The Hobbit: The Desolation of Smaug that has some pretty fancy effects. While I was playing with it I wondered what open source WebGL stuff people had been making, which is when I found this simple zombie game.

This ain't The Walking Dead, but where's your zombie game?

The source is here: Goobuzz / NavMesh-Project, and there’s a reddit thread which I think the author started.

WebGL Debugging and Profiling Tools

WebGL Debugging and Profiling Tools by Patrick Cozzi has a whole load of resources for working with WebGL. He covers a Firefox WebGL shader editor, WebGL Inspector, Chrome Canvas Inspector, Google Web Tracing Framework, and more.

He even includes useful performance tips:

Depending on how many frames the GPU is behind, a better practice would be to do all the texSubImage2D calls, followed by all the reprojection draw calls, or even move the reprojection draw calls to the end of the frame with the scene draw calls. The idea here is to ensure that the texture upload is complete by the time the reprojection draw call is executed. This trades the latency of completing any one for the throughput of computing many. I have not tried it in this case so I can’t say for certain if the driver lagging behind isn’t already enough time to cover the upload.

And is glad to see browsers including developer tools for WebGL:

Building WebGL tools, such as the Firefox Shader Editor and Chrome Canvas Inspector, directly into the browser developer tools is the right direction. It makes the barrier to entry low, especially for projects with limited time or developers. It helps more developers use the tools and encourages using them more often, for the same reason that unit tests that run in the blink of an eye are then used frequently.

JavaScript Developer Survey 2013: RFC

21 Nov 2013 | By Alex Young | Comments | Tags community surveys

Every year I like to run a survey for the readers of DailyJS. It helps me figure out what I should write about, but I also share the results with the community so you can use the data however you wish.

This year I’ve decided to change the approach. A draft of the survey questions can be found on GitHub, here: alexyoung / dailyjs-survey. You can fork it and send pull requests for questions you’d like to add or change.

After a week or so I’ll compile the changes into a Google Drive form and announce the survey has gone live so people can submit their responses.

I’d really appreciate input on the survey before publishing it, because it helps us get a better idea about what’s going on in the world of client-side and server-side JavaScript development.

Node Roundup: Fowl, grunt-ec2, connect-body-rewrite

20 Nov 2013 | By Alex Young | Comments | Tags node modules grunt amazon foundationdb express

Fowl

Fowl (GitHub: OptimalBits / fowl, License: MIT, npm: fowl) by Manuel Astudillo is a document and query layer for FoundationDB. It provides a similar API to NoSQL databases like MongoDB, but has support for multidocument transactions:

Transaction support is an incredibly powerful feature that simplifies server logic and helps avoiding difficult to solve race conditions.

Fowl provides a low level API based on keypaths for describing documents and its properties following CRUD semantics.

It includes tests and each API method is documented in the readme file. Basic usage looks like this:

// Open a foundationDB database
fowl.open();

// Create a document (if _id not specify a GUID will be generated)
var john = fowl.create('people', {
  _id: 'john',
  name: 'John',
  lastname: 'Smith',
  balance: 100
});

// Use transactions to transfer money from one account to another
var tr = fowl.transaction()

tr.get(['people', 'john', 'balance']).then(function(johnBalance) {
  tr.put(['people', 'john', 'balance'], johnBalance - 10);
});

grunt-ec2

grunt-ec2 (GitHub: bevacqua / grunt-ec2, License: MIT, npm: grunt-ec2) by Nicolas Bevacqua is a set of Grunt tasks for creating, terminating, and deploying Node applications to AWS EC2 instances.

The deployed Node applications are served from behind an Nginx proxy. The task reference explains what each task does – there are quite a few.

It supports most of the things you want to do when setting up Node applications, including SSL, SSH keys for each instance, rsync support for fast and painless uploads, and hot code swaps.

connect-body-rewrite

There are times when the logic of my Node web applications have seemed to need the response body to be rewritten, but in the middleware rather than the main route logic. The connect-body-rewrite (GitHub: rubenv / connect-body-rewrite, License: MIT, npm: connect-body-rewrite) by Ruben Vermeersch makes this possible. The examples use regular expressions to replace text, based on the request headers:

app.use(require('connect-body-rewrite')({
  accept: function (res) {
    return res.getHeader('content-type').match(/text\/html/);
  },
  rewrite: function (body) {
    return body.replace(/<\/body>/, "Copyright 2013 </body>");
  }
}));

I like the way it’s designed to use an accept callback, because it makes it easy to see what the rewriter actually does by keeping the logic close together.

Chained, Door

19 Nov 2013 | By Alex Young | Comments | Tags jquery es6 components libraries

Chained

Chained (GitHub: vzaccaria / chained, License: MIT) is another ES6 experiment. It allows APIs that return promises to be mixed with functions that take parameters and return mutated objects. In Vittorio’s example he mixes jQuery’s network methods with Underscore.js to download JSON and then filter it:

getUser = (user) ->
  _("https://npmjs.org/~#{user}")
    .get()
    .extractLinks()
    .filter(-> /package/.test(arguments[0]))
    .map(-> "https://npmjs.org#{arguments[0]}")
    .log()

getUser("vzaccaria")

In this CoffeeScript example, methods that use promises (get) are mixed with functions that take objects as the first argument (filter, map), using a consistent chainable API. To make this work, Vittorio has used ES6’s introspection features.

The project has detailed notes in the readme about how this works. He mentions that the library came about after trying to create DSLs with JavaScript.

Door

Olivier Wietrich sent in Doors (GitHub: bredele / doors, License: MIT, component: bredele/doors), a module for conditionally restricting access to open events that are triggered when all locks are unlocked.

[State machines and promises] both have something missing. A transition occurs when one condition is triggered. Things are not so simple in real life. You will probably have more than one condition to do something, but one condition is sufficient to not do it. Think about a door with multiple locks: you can’t open the door until all locks are unlocked.

Looking at the documentation, it seems like the author wants to use it to restrict access to an API until certain authentication preconditions are met. There’s a simple HTML example that uses a graphical door, and two locks. You can toggle locks and add more.