The Future of Node is in Microsoft’s Fork

Node.js is a platform for running JavaScript (ECMAScript) that is powered by Google Chrome’s JavaScript engine, V8. V8 pushed JavaScript forward in terms of speed when it was first released, but hasn’t been keeping up with the accelerated pace of the ECMAScript Standard. We’ll likely see a new release of the spec every year, but V8 is lagging far behind Mozilla’s SpiderMonkey and Microsoft’s Chakra in terms of support for ECMAScript 2015 (aka ES6).

Node.js developers that have been eager for ES2015 features that V8 doesn't yet support have turned to Babel.JS for compiling their ES2015 code into ES5 code, but this only works for syntax features like arrow functions. There are features within ES2015 that Babel.JS can’t emulate because ES5 fundamentally lacks the ability accomplish these features in any reasonable way, namely the Proxy constructor and extending built-in objects like Array.

[Update: This controversial statement has been too distracting.] The Node.js Foundation would be wise to migrate to Chakra, because Google’s updates are coming in at a trickle while Microsoft’s are roaring in like a river, but that’s not really the point. The point is that these features are coming regardless, and you can play with them now. With an annual ECMAScript releases adding new features, Microsoft's Node.js Chakra fork will continue to outpace Google's V8 engine by months. So long as Microsoft maintains their fork, we’ll be able to preview features that aren’t yet ready in V8.

In order to use Microsoft's fork, you need a Windows 10 machine with the November update. It’s a huge update, so just because you have auto-updates enabled doesn’t mean that you have it (this messed me up). For the full instructions, look at an individual release on github, currently v1.3.

Once you have that working, you can play with features that V8 and Babel don't support, like proxies in this example:

const someObject = {};

const someProxy = new Proxy(someObject, {
  get: function (target, property, reciever) {
    if (property.substr(0, 6) === 'happy_') {
      return Reflect.get(target, property.substr(6), reciever);
    return 'sad';
  set: function (target, property, value, reciever) {
    if (property.substr(0, 6) === 'happy_') {
      return Reflect.set(target, property.substr(6), value, reciever);
    return false;

someProxy.happy_x = 'happy';
console.log(`someproxy.happy_x = 'happy';`);
console.log('someProxy.x:', someProxy.x);
console.log('someObject.x:', someObject.x);
console.log('someProxy.happy_x:', someProxy.happy_x);
console.log('someObject.happy_x:', someObject.happy_x);


someproxy.happy_x = 'happy';
someProxy.x = sad
someObject.x = happy
someProxy.happy_x = happy
someObject.happy_x = undefined

@kangax maintains an ECMAScript Compatibility Table where you can compare support for Node.js and Edge for several versions of ECMAScript so that you know what features to explore with Microsoft's Node.js fork.

Feel free to poke me on Twitter @fritzy if you have any thoughts or feedback.

Update (Dec 31, 2015):

There are several people pointing out that Chakra isn't open source. However, it is going open source in January, and cross platform afterward.

My main point is not that ChakraCore should be the new Node.js JavaScript engine, but that Microsoft's fork of Node.js with ChakraCore in it is a pretty handy way to preview Node.js's future, regardless.

Update (Jan 2, 2015):

I've been receiving a lot of feedback. I'm removing my statement saying that Node.js should move to Chakra -- that was meant to be controversial and get people thinking, but it has proven distracting to my main point, that you can play with Microsoft's Fork to preview features that they have that Node.js doesn't yet have.

Mikeal Rogers pointed out that I was making an inappropriate suggestion for the Node.js Foundation:

He goes on to give some more context:

Several people pointed this out:

In fact, Jake Archibald references a tweet showing that the V8 team has been catching up:

Mostly, I'm excited to see the Node.js platform have some diverse implementations. I'm hoping we see more of this.

I mentioned that I recalled a similar Mozilla effort in the past, and Brendan Eich pitched in with the details:

Personally, I'd love to see Mozilla come back and do this again; diversity makes for a healthier ecosystem.

This does raise the question: is there a better long term solution for multiple JS engines than V8 API shims?

Keep the feedback rolling.

Enjoy this post? We'd love to invite you to join our mailing list, &you, where we connect with our community and share the latest we're learning.

You might also enjoy reading: