The JavaScript blog.


libraries node modules npm async iojs

Node Roundup: npm 3, io.js 1.4.3, NoDent

Posted on .

npm: Roadmap for 3, Using jQuery Modules

The npm roadmap has been updated with details on npm. This includes multi-stage installation, improvements to shrinkwrap, and progress bars. There's an entry that aims to solve the front-end tooling problem, and I noticed shipping HTML and CSS is mentioned. I prefer a Browserify/npm-based workflow, but I've always found this stage less than elegant, so it'll be interesting to see what happens there.

To read more, visit the npm blog. There's also another interesting post about jQuery, which describes how to use jQuery plugins through npm. The previous post on jQuery was about publishing modules, but this one shows how to consume plugins even if they don't use npm.

io.js 1.4.3

There was a new io.js release (1.4.3) on Monday, which has quite a big fix for streams on Windows and the beginnings of ARM support. The 1.4.x branch was released at 1.4.1 due to a libuv bug in 1.4.0. This branch adds newer versions of V8, npm, and libuv, but also has improvements for process, stream, and http.

For more details on io.js and npm changes, you can look at the changelogs on GitHub:

They're both nicely annotated with links to commits, and summarise major changes.


In my DailyJS email backlog I found NoDent (GitHub: MatAtBread/nodent, License: BSD-2-Clause, npm: nodent). It's a small module that adds support for the proposed aysnc and await keywords. They're not too hard to learn, and once you get used to them they can make asynchronous code more readable.

The basic idea is to mark asynchronous functions with the async keyword, and then use the await keyword before they're called.

async function tellYouLater(sayWhat) {  
  // Do something asynchronous and terminal, such as DB access, web access, etc.
  return result;

var result = await tellYouLater('Hi there');

This will cause execution to wait until tellYouLater returns. I've used async/await in C#, and it works well for methods that return a single value (rather than an observable with a sequence of values).

The author's readme has lots of examples of uses and abuses, so it's worth reading if you seriously want async/await now.


frameworks libraries node modules express async promises

Node Roundup: promise.io, copromise, Apper

Posted on .


promise.io (GitHub: krillr / promise.io, License: Apache 2.0, npm: promise.io) by Aaron Krill is an RPC module that uses promises. You can create a server like this:

var server = new PromiseIO({  
  someFunc: function(input) {
    return 'I got: ' + input;


Then the client can call someFunc by connecting to the server:

var client = new PromiseIO();

client.connect('http://localhost:3000').then(function(remote) {  
  return remote.someFunc('my variable!');
}).then(function(returnVal) {
  return console.log(returnVal);
}).catch(function(err) {
  return console.log(err);

Internally, q is used for the promise implementation.


copromise (GitHub: deanlandolt / copromise, License: MIT, npm: copromise) by Dean Landolt is a bit like co, but it automatically lifts values that aren't promises, so you can yield anything.

A copromise represents the eventual value of a coroutine. A coroutine is a generator function where the yield keyword is used to suspend execution to wait on a future value, allowing linear control flow logic for asynchronous code.

Dean announced it on the nodejs list, including some examples and a comparison with the co module.


Apper (GitHub: asyncanup / apper, License: MIT, npm: apper) by Anup Bishnoi is a real-time framework for single page applications. The idea behind it is to have strong conventions for practices that suit single page apps, including transparent minification and bundling.

It wraps around Express, so route definitions look like a typical Express project, but Apper also has specific places for things like middleware and application settings.

If you're new to Express then you might like working with the conventions Apper uses, and it will at least push you away from putting everything in a monolithic app.js file.


async promises ES6

Miminal Promises with Thenable

Posted on .


If you want to use ES6 promises using the Promise object in a library or module, then there's a new implementation that you might want to check out. Thenable (GitHub: rse / thenable, License: MIT) by Ralf S. Engelschall is a Promise implementation based on Promises/A+.

This is a strictly-compliant Promises/A+ 1.1.1 implementation in just 2KB of (compressed) code, which passes the official Promises/A+ Test-Suite and includes back-references to the relevant specification statements. It just provides a minimum Promise functionality, because it is intended to be directly embedded into ECMAScript 5 based libraries and frameworks, in order to dependency-free leverage from Promises and be able to return "thenable" Promise objects to applications.

Because Thenable is a minimum implementation of Promises/A+, it's suited to the creation of libraries that are forwards compatible, rather than for consumption in JavaScript applications. To reinforce the point, Ralf hasn't published it to npm or Bower.

Instead, please download the raw thenable.min.js and include it verbatim into your library/framework. The usual approach for this is to temporarily emulate a CommonJS environment within your library/framework to get its Thenable object.

It has a noConflict option for browsers, and supports AMD, CommonJS, and browsers.

If you want to use Promises/A+ in your applications, Ralf recommends Bluebird, and there's a large list of other implementations on the promises spec wiki: promises-spec / implementations.md.


performance async

Script-injected Async Scripts Considered Harmful

Posted on .

Ilya Grigorik has published a post about how script-injected resource loading could negatively impact performance, in Script-injected "async scripts" considered harmful.

The inline JavaScript solution has a subtle, but very important (and an often overlooked) performance gotcha: inline scripts block on CSSOM before they are executed. Why? The browser does not know what the inline block is planning to do in the script it is about to execute, and because JavaScript can access and manipulate the CSSOM, it blocks and waits until the CSS is downloaded, parsed, and the CSSOM is constructed and available.

The example in the article shows a CSS download blocking script execution, where the scripts are short snippets that inject additional script elements to load real JavaScript files. The delay of execution causes the files to be downloaded later than desired.

If you look at the source to DailyJS you can see Disqus injecting a script that way, and when I look at the network tab in Chrome Developer Tools it seems like count.js executes after the CSS files have downloaded.

The obvious fix is to use async attributes on script tags, as long as you can live with the additional effort to support IE8 and 9. But before you rush off to reformat your sites, the last point by Ilya is interesting:

Wait, should I just move all of my JavaScript above the CSS then? No. You want to keep your <head> lean to allow the browser to discover your CSS and begin parsing the actual page content as soon as possible - i.e. optimize the content you deliver in your first round trip to enable the fastest possible page render.

Optimising for all possible browser behaviours is difficult!


firefox async ES6

Async Harmony Tests

Posted on .

Simeon Velichkov sent in async-harmony tests (GitHub: simov / async-harmony, License: MIT), which contains examples of new ES6 features. Each example is based on methods from async, but written using new features like generators, including arrow functions.

It only currently works in Firefox 29, but I thought the examples were quite interesting:

function eachSeries (items, job, done, kill=true) {  
  var results = [], errors = [];

  var it = iterator();

  function* iterator () {
    for (let item of items) {
      yield job(item, (err, result) => {
        if (kill && err) return done(err);
        if (err) errors.push(err);
        setTimeout(() => it.next(), 0);
    done((errors.length ? errors : null), results);

The corresponding usage looks like this:

async.eachSeries([0,1], (item, done) => {  
  done(new Error('error'+item));
}, (err, result) => {

Give them a read if you're interesting in seeing ES6 in action.