The JavaScript blog.


frameworks node ES6 iojs

Nodal: An ES6 API Server

Posted on .

Sometimes I feel like client-side developers are adopting ES6 faster than server-side developers. I certainly have projects where the client uses ES6 and the Node server code is more ES5, mainly because I don't really want to use a transpiler on the server, although I sometimes do like to use Harmony flags.

Alternatively, I could use io.js. Keith Horwood recently sent in a new module that aims to provide an API server and web framework that takes advantage of ES6 features. It's called Nodal (GitHub: keithwhor/nodal, License: MIT, npm: nodal) and currently runs on io.js.

Nodal includes support for models, controllers, templates, migrations, routing, and query composition. It has a command-line tool for creating RESTful resources, and it's designed to work with PostgreSQL.

The example code makes heavy use of new language features like const and classes. The result is very Rails/Django-like. Here's a snippet of a model class:

module.exports = (function() {  
  'use strict';

  const Nodal = require('nodal');

  class Person extends Nodal.Model {
    __preInitialize__() {}
    __postInitialize__() {}

  Person.prototype.schema = Nodal.my.Schema.models.Person;

  Person.prototype.externalInterface = [

  return Person;

It doesn't have the same kind of auto-loading magic that you see in Rails -- notice the Nodal module is loaded explicitly. It still feels like idiomatic JavaScript rather than using ES6 to pretend to be something else.

Nodal doesn't use an external ORM, it actually has its own models backed by any-db-postgres. That means Keith is developing features like model relationships. I've tried to develop my own ORM before, and the ORMs I've used before have been very mixed in terms of quality and consistency between releases, so I don't envy the work he has ahead. However, the idea of a RESTful web framework that takes advantage of ES6 for code organisation and clarity is interesting, so let's see what he does with it!


node iojs

io.js Joins the Node.js Foundation

Posted on .

When io.js got started there were those that saw it as the "new Node", a more aggressively developed fork that quickly implemented features that were lacking from 0.11 and 0.12. And the lack of the mystical Node.js 1.0 in 2014 certainly encouraged that kind of attitude. We were waiting for an updated V8 with the ES6 features that we wanted and more mature core modules, but what we got was leadership changes and talk of a "foundation".

A week ago the io.js Technical Committee met and voted to merge with Node under the Node.js Foundation. This is summarised in the May 13th Technical Committee meeting notes:

Voting Question: The io.js TC agrees to:

  1. have the io.js project join the Node Foundation

  2. rename the entire "iojs" GitHub org to be "nodejs"

  3. invite the the current Node.js TC on to our TC to form the basis of a Node Foundation TSC under the policies of the Node Foundation

  4. moving the io.js Working Groups to be under the Node Foundation

Mikeal Rogers wrote a post about why io.js needs a foundation, which includes some background about why io.js forked from Node, what it achieved, and what needs to happen next:

However, without a legal entity to own property it means that various io.js assets are in reality owned by individuals and companies. The domain name is owned by Fedor, the billing contact for the GitHub org is Colin, the keys used for signing the releases are owned by NodeSource, etc. With all the current owners acting in good faith this ownership isn’t an immediate problem, just as it wasn’t a problem for node.js in 2012, but the more successful we are the worse it could be, so this is something that keeps me up at night.

There's also a GitHub issue about this with a lot of positive support from the community. Later on, Mike Dolan (Director of Strategic Programs at The Linux Foundation) summarised the io.js merge on the official Node blog in Node.js and io.js leaders are building an open, neutral Node.js Foundation to support the future of the platform:

Most recently the io.js TC voted to join in the Foundation effort and planning is already underway to begin the process of converging the codebases.

It sounds like everyone is doing the right thing: Node has shifted to an open model with support from the Linux Foundation, and io.js has recognised the need to seek a more formal management model.

The next steps from a technical perspective will be difficult: merging commits from io.js won't be trivial, and even resolving details like moving GitHub issues will take time.

I expect the merged Node.js will not be a 0.12 release, and from the io.js commits I've been watching over the last few months there may be some small backwards compatibility issues, but hopefully this brings us closer to a Node that can keep up with modern JavaScript. It seems like we're finally seeing a Node with the right kind of management and technical progress that we expected from the heady success of earlier releases.


libraries console node apps modules npm iojs

Node Roundup: TJ Steps Down, Node and io.js Performance, Cloud Commander, Blessed

Posted on .

TJ Steps Down

Timothy J Fontaine has stepped down as the leader of the Node project:

Given the strength of its community, I'm confident that Node.js is heading in the right direction. With that said, it's time for me to step back.

The formation of the Node.js Foundation couldn't have happened at a better time in the life of Node.js. I believe this will be the tipping point that cements Node's place in technology. Soon, the foundation will be announcing its first meeting, initial membership, and future plans for Node.js.

The announcement includes details about Julien Gilli's work on the project, who is paid as a full-time developer on Node itself:

Julien has been responsible for the last few releases of Node.js -- both the v0.10 and v0.12 branches.

Thanks to him, we were able to ship v0.12.0 with all our tests passing and on all of our supported platforms. This was the first Node.js release ever to have that feature.

There's also another post on the Node blog by Scott Hammond that reiterates the move towards the Node.js Foundation:

Under the aegis of the Foundation, the Node.js project is entering the next phase of maturity and adopting a model in which there is no BD or project lead. Instead, the technical direction of the project will be established by a technical steering committee run with an open governance model.

That all sounds promising, except most of us just want a Node that has ES6 features without flags and continued updates to the V8 core. Naturally that brings me to io.js which just hit version 2.0.1. This release updates libuv and V8, and has fixes for async-wrap, documentation, and some of the internal C++ in the src/ folder. And you may also remember that the io.js 2.0.x branch has enabled lots of ES6 features without flags.

Node and io.js Performance

Nick Harley sent in Performance Showdown: Node.js vs. io.js v2.0.0:

A 14.8% speedup from Node to the latest version of io.js - certainly worthy of note. If you’re looking at one of the latest generation of JS backend frameworks, it certainly pays to give io.js a look as out-of-the-box you get some rather impressive perf improvements. When running a cluster of VMs using the Node stack, depending on scale, that speedup may result in several fewer boxes needed and correspondingly less infrastructure costs - all for free.

Cloud Commander

Coderaiser sent in Cloud Commander (GitHub: coderaiser/cloudcmd, License: MIT, npm: cloudcmd), a Node app that's been under active development since 2012. It's a file manager that reminded me of a web version of Midnight Commander, and it bundles CodeMirror and Ace so you can edit code with it quite comfortably.

It's built with Express and Socket.IO, and I was pleased to see they're on Express 4.x. The documentation the homepage includes details on how to deploy it with a non-root user for Linux/iptables or nginx.

The web app has a console interface as well, so you can type commands rather than using the web GUI.

Blessed and Blessed-Contrib

A colleague kept telling me how good Blessed-Contrib was, and I've only briefly mentioned Blessed on DailyJS before so I wanted to mention it. The attached gif illustrates why. Blessed is a curses-like library, but it has a very high-level API that I find much easier to understand than most terminal GUI libraries.

However, the magic really happens when you get blessed-contrib:


I've been waiting for something like this for years but never found a high-level scripting language library good enough to make my 1980s Unix console UI fantasies come true. Now I can finally bring to life my W.O.P.R version of our status dashboard!


libraries node modules npm build iojs

Node Roundup: Node 0.12.2, io.js 1.6.3, JXcore, Osmosis

Posted on .

Node 0.12.2

Is Node ramping up to regular iterative releases again? This week Node 0.12.2 was released, which upgrades the core binary dependencies, fixes a V8 issue, and has bug fixes for the core modules. Some of these commits go back to things we saw in February in io.js that I believe came from commits to Node that io.js picked up. For example, the commit for allow Object.prototype fields as labels goes back to a backport of an earlier commit.

Comparing the commits in 0.12.2 to io.js's changelog shows that most of them have already been released -- the newest commit currently in Node's stable branch was in io.js 1.5.

Speaking of io.js, yesterday io.js 1.6.3 was released. There's a bug fix for fs that stood out to me:

  • [c9207f7fc2] - fs: fix corruption in writeFile and writeFileSync (Olov Lassus) #1063

And there are several commits that improve code quality. This release seems pretty big, so keep an eye on their weekly review post on Medium for an overview.


There are more Node forks out there! JXcore (GitHub: jxcore/jxcore) is a Node-compatible platform that aims to support mobile devices. It's embeddable, supports multiple JavaScript engines (V8 and SpiderMonkey), and also supports ES6.

One of the core developers, Ugur Kadakal, sent me an email about the project, and claimed it allows applications to run on iOS. I found a blog post with more details. There's also documentation for compiling native apps with jx. I haven't tried this myself, but it sounds like they've done an impressive amount of work on it so far.


Here's a new web scraper for Node: Osmosis (GitHub: rc0x03/node-osmosis, npm: osmosis). It doesn't have any HTML parsing dependencies because it uses libxml C bindings instead. It supports both CSS and XPath selectors.

The API includes HTTP and is chainable, so you can do osmosis.get(url).find(selector).data(callback) to pull out elements for a selector. You can also open new URLs based on selectors using follow, and transform data using set().

The underlying HTTP layer is provided by needle. Needle itself is an amazing HTTP client, supporting streaming decompression, multipart forms (uploads), character encoding support with iconv-liteiconv-lite, and proxies.

If you're doing lots of scraping, then Osmosis looks like a solid library to try out. The other one that I've recently been impressed by is X-Ray.


libraries node modules npm build iojs

Node Roundup: Node 0.12.1, io.js 1.6.2, DIY, Typescript-Deferred

Posted on .

Node 0.12.1

Yesterday Node 0.12.1 was released. It has OpenSSL fixes for security vulnerabilities that include a DoS. Two fixes are ranked as high, and nine are marked as moderate.

io.js just hit version 1.6.2. The recent io.js releases have had tls and http fixes, but there are other very interesting changes if you dig into the changelog. For example, the Node binary can now be invoked with a list of modules to preload:

iojs -r foo -r /bar/baz.js -r quux  

This is equivalent to:


The reason I like this is it means environment-specific modules can be loaded without changing your code. You could use this to load modules that instrument the runtime with debugging and logging functionality.

The npm blog (yet again) has a useful post for client-side developers: Using Angular's new improved Browserify support:

With the recent release 1.3.14 instantaneous-browserification, Angular introduced better support for those using Browserify. Thank you to everyone who worked on that issue, and especially to Ben Clinkinbeard for his unflagging dedication in getting it in.

I prefer reading AngularJS code with CommonJS modules, so it would be cool to see AngularJS module maintainers using Browserify for modules on npm.

DIY: JavaScript that Compiles to a Makefile


I've used Gulp and Grunt to manage client-side builds, but as someone who used to write makefiles I'll admit to wishing everyone just used make. Well, now maybe we can, with Vittorio Zaccaria's DIY (GitHub: vzaccaria/diy, License: BSD, npm: diy).

Here's a sample configuration file:

generateProject(_ => {  
  _.collectSeq("all", _ => {
    _.collect("build", _ => {
      /* specify how to build files */
    _.collect("deploy", _ => {
      /* specify how to deploy files */

DIY is a DSL for describing build processes. The generateProject function is used to wrap calls to various methods that describe build steps. The final makefile is generated by using babel, so you just have to type babel configure.js | node. Once you've got a makefile you can invoke the targets that were defined by calls to the collect method.

This module gets top marks for using Babel and for generating something that's friendly for Unix grumps like me.


What if you want TypeScript-friendly promises? Typescript-Deferred (GitHub: DirtyHairy/typescript-deferred, License: MIT, npm: typescript-deferred) by Christian Speckner is a Promises/A+ implementation written in TypeScript. The author says nobody needs another promises implementation, but this implementation is pretty cool: it has no dependencies, and fully implements the specification.

If, like me, you're a TypeScript tourist, then here's what strongly typed promises look like:

// A promise for a number that resolves to 10
var promise: tsd.PromiseInterface<number> =  

// A promise that adopts the state of some other thenable that wraps a value
// of type sometype
var promise: tsd.PromiseInterface<number> =  

Christian suggests that this will be useful if you want to embed a small promises implementation into your own libraries.