
Node.js ES2015/ES6 support - tilt
http://node.green/
======
amelius
I'd like to see a performance comparison with older versions. Some people here
noted that these new ES2015/ES6 features are hurting the performance of old
features. I have no idea whether this is true, so I think it would be best to
just have the numbers.

~~~
Ambroos
A bigger 'issue' for now is that most ES2015 features are (much) slower than
their ES5 equivalents. Code transpiled with Babel will usually run quite a bit
faster than running ES2015 directly, especially with Babel in loose mode.

~~~
untog
Does anyone have a decent explanation of why? I'm confused why () => {} would
be slower than function(){}.bind(this).

~~~
tracker1
Becaue that binding is tigher than...

    
    
        (function(){ 
          var __that = this; 
          return function(){
            /*switch __thatthat/this ref*/
          }; 
        }());
    

The code in question isn't just a binding, and it will have other
differences... The code above is similar to what babel does iirc.

Now, that said there are other differences, such as ensuring that let
variables are properly scoped and const doesn't allow reassign... that doesn't
even begin with the maps and other new strong types that require additional
locking and checks that will be less performant in many scenarios.

It's more about stable software with understandable, manageable code more than
it is absolute, raw performance.

------
Illniyar
This doesn't seem like a complete list, what about modules? (I.E.
import/export) which is (at least for me) the most interesting thing in es6
that needs to be implemented in node.

~~~
Touche
Why do you think it's important that they implement import/export? Node
already has a module system that works well. Support import/export is much
more important in Browsers which has no module system.

~~~
ihsw
Because this one is superior. Why do we have cars if we can all walk just
fine?

~~~
Touche
In what way is it superior?

~~~
edwinjm
For one, CommonJS doesn't work well in the browser.

~~~
tracker1
Browserify and Webpack bundling seems to work pretty well.

I agree that getting ES6 modules in the browser will be nice, in the end, I
see it working in practice a lot like it's implemented in Babel, to work with
CJS modules.

------
islon
I wish they were adding power to js as they did to Lua: with simplicity.

Instead they are doing doing the C++/Scala way: with complexity.

Good thing I have Clojurescript...

~~~
spriggan3
> Good thing I have Clojurescript...

which depends on the JVM ...

ES6 has nothing to do with either C++ or Scala. It takes most of its new
syntax from Python.

~~~
_pmf_
> which depends on the JVM ...

Which has a mature ecosystem managed by people experienced in maintaining
software over a decade or more.

------
neals
So I'm an above average JS developer. I feel save saying this and claiming
this.

I would never use _most_ of the exotic new stuff and I would probably never
use any of the red stuff.

I'm not saying it shouldn't be in there. I love that JS can be a fit for
everybody. I just wonder how much we're gonna be adding and when it's
enough...

~~~
terda12
Some things I like about ES6

1\. Arrow functions are really handy:

    
    
      ["the", "red", "fox"].map(word => console.log(word))
    

is much cleaner than

    
    
      ["the", "red", "fox"].map(function(word) {
          console.log(word)
      })
    

2\. Imports, while more ambiguous than `require`, look quite nice:

    
    
      import React, { Component } from 'react';
      import Block from './Block';
    

vs

    
    
      var React = require('react');
      var Block = require('./Block');
    

3\. Exports are cleaner and streamlined

    
    
      export default myFunction()
    

vs

    
    
      module.exports = myFunction()
    

So while ES6 is more ambiguous than ES5 and has a higher learning curve, I
think it's much cleaner and looks more like a proper programming language. ES5
feels like a homegrown hacky language in comparison.

~~~
mbrock
The code I write in ES2015 makes very heavy use of arrow functions,
destructuring parameters, the ellipsis syntax for extending arrays and
objects, and the syntax for evaluated object literal keys.

Random example:

    
    
        DRAFT_LOADED: ({
          state: { drafts },
          payload: { draft }
        }) => ({
          drafts: {
            ...drafts,
            [draft.id]: draft
          }
        })
    

In classic JavaScript, I'd have to write something like:

    
    
        RESULTS_LOADED: function(state, payload) {
          return {
            drafts: Object.assign(
              {}, state.drafts,
              keyValue(payload.draft.id, payload.draft)
            )
          }
        }
    

The new syntax rules combine to significantly improve the clarity of this kind
of transformation function.

~~~
z3t4
hmm. Looks like some sort of exploit. Tried to run it in node and got some
weird error I haven't seen before. Did you just pwn me?

~~~
mbrock
haha, no... I haven't tried it in pure Node, I'm using Babel for transpiling.

------
jarcane
I can't help but notice that once again tail call optimization seems to be one
of the last things added, and even then requires a specific flag to work.

Is there some reason for this pattern, like actual performance/technical
difficulties, or is it more "My Java/C professor said recursion is bad"?

~~~
epmatsw
From my understanding, there's not a lot of performance benefit in most cases
and a performance degradation in others. Also there's some reluctance to
change the behavior of existing code. Plus a whole bunch of unaddressed
debugging issues (what does console.stack show?).

[https://github.com/tc39/proposal-ptc-
syntax](https://github.com/tc39/proposal-ptc-syntax)

~~~
cpeterso
Also, how would script feature detect whether the VM implemented TCO? Code
written assuming TCO would still run, but very inefficiently.

~~~
dsp1234
For Node.js, define a simple function that does minimal computation, but that
would blow the stack if called say a million times[0]. Run that function
inside of a new vm context[1]. If it errors with a stack overflow, then no
TCO.

[0] - function n(x){if(x > 0) n(x-1)}

[1] -
[https://nodejs.org/api/vm.html#vm_vm_runinnewcontext_code_sa...](https://nodejs.org/api/vm.html#vm_vm_runinnewcontext_code_sandbox_options)

------
iamleppert
It seems crazy to me that performance takes a backseat to syntactical sugar,
which is most of what ES6 provides. There are a few new constructs, but in my
mind when is it ever acceptable to have performance regressions to make the
code look pretty?

And the fact that it isn't optional is alarming. If you use the new features,
you should have to suffer performance penalty if there is one, and at least be
able to make that design choice and trade-off between "cleaner" or "prettier"
code and poor performance.

I don't think you can call something "complete" or green until the performance
issue is solved.

~~~
tracker1
It's better to make something that works, and then improve performance as-
needed than to try and optimize before hand. You don't always know the real
world impact of a given solution until you have one, and synthetic tests
aren't a reflection of real world impact.

Beyond this, I happen to like a lot of the sugar. It makes code simpler,
cleaner and in most cases easier to comprehend... Sometimes the fat arrow
functions returning fat arrow functions gets a little weird, but outside of
that, it's a pretty big benefit. Async functions will help a lot as well once
they land, for now, Babel works well enough.

------
tracker1
I think it's awesome how well the V8 team is working on these features, and
how much more closely the Node core teams are working with the V8 teams. Much
better coherence than in the past. (at least from the perspective of a mostly
passive observer).

There are a few bits wrt ES2016/2017 that I'm hoping come in before long as
well... will be nice to no longer feel the need for babel, at least on the
server-side pieces of many projects.

------
mirekrusin
Wow, Proxy is there, awesome. I find it strange nobody mentions Proxy, it's so
cool to finally have it...

~~~
coroutines
We are now friends. Hello friend. :D

------
rail2rail
Would be great if each section linked to a description of the functionality.
This would help new users and those trying to level up skills. Sure you can
just Google it, but it would make this chart that much more useful.

------
paradite
Does anyone know if Node.js will have backports for ES6 in version 4.X? Would
love to use ES6 in my current project but I don't want to move from Node.js
4.X to 5.

~~~
jyunderwood
I would assume the answer is no. Backporting ES6 features could introduce some
breaking changes. You could transpile your code with something like Babel[1].

[1][https://babeljs.io/](https://babeljs.io/)

~~~
tracker1
I'm a fan of async functions, so will be using Babel on the front and back for
a while to come.

------
kapv89
Really Impressed by how quickly node.js has moved after the merge with io.js
and the formation of node foundation.

