
V8 Release 5.1 - kenOfYugen
http://v8project.blogspot.com/2016/04/v8-release-51.html
======
inglor
In case anyone is wondering, NodeJS v6 is right around the corner with V8 5.x.
Node is going to get a serious boost of ES2015 features.

Including but not limited to: Proper tail recursion (^_^) and destructuring.

Tracked at [http://node.green](http://node.green)

We don't have an ES2015 features page up to date yet, but it's going to be
ready any day now (and we're going to link to node.green anyway most likely).

~~~
ofrobots
To be precise, Node.js 6.x will include V8 5.0. There has been a little
discussion on being able to include V8 5.1 down the road, maybe, but there is
nothing concrete on it at this point.

Also, the fate for tail-call-elimination is pretty uncertain at the moment;
see: [https://github.com/tc39/proposal-ptc-
syntax](https://github.com/tc39/proposal-ptc-syntax)

~~~
inglor
Oh hi, fancy seeing you here :]

Note that ptc syntax _ensures_ tail calls, tail calls themselves have
_already_ been approved in ES2015 and are live in V8 (under a flag), you can
follow their status here:
[https://bugs.chromium.org/p/v8/issues/detail?id=4698](https://bugs.chromium.org/p/v8/issues/detail?id=4698)

------
hacker_9
_" WASM

5.1 has a preliminary support for WASM. You can enable it via the flag
--expose_wasm in d8. Alternatively you can try out the WASM demos with Chrome
51 (Beta Channel)."_

The future is coming fast.

~~~
qaq
Y but how long will it take to get to the point where enough users have
browsers that support WASM ? 10 years?

~~~
IvanK_net
It took WebGL about 4 years to spread, the reason it took so long was in
hardware (GPU, drivers ...). Wasm is just CPU-related, I believe it can reach
most of the people within a year.

Pouplar browsers get updated quite often. And those, which got updated rarely,
became unpopular. Everything will be fine, I think :)

~~~
untog
One of the major drags on WebGL was a lack of iOS support. Once that was in
place there was an explosion in usage. I suspect we'll see the same here.

~~~
pjmlp
WebGL still sucks on mobiles.

90% of the time someone puts a link to some WebGL demo on HN or Reddit I
either don't get it running at all, or get single digit FPS after the mobile
turned into oven mode.

------
Rezo
What's the latest word on native ES2015 module support (i.e. the import
keyword) in V8 or Node.js? Every ES2015 comparison table I know omits it, but
it's the big one that could significantly reduce the modern JS toolchain
complexity.

~~~
nostrademons
[https://bugs.chromium.org/p/v8/issues/detail?id=1569#c53](https://bugs.chromium.org/p/v8/issues/detail?id=1569#c53)

There's been some activity lately, but so far just looks like they're laying
groundwork. Dunno where it is in the priority list. The last blocker was
supposedly the finalization of the HTML5 module-loader spec, and that came out
a couple weeks ago.

------
amelius
Did they run speed benchmarks against older versions of V8?

I'm wondering about the performance cost of these new features (hopefully
zero).

~~~
chr1
Unfortunately it is much larger than zero see
[https://groups.google.com/d/msg/strengthen-
js/ojj3TDxbHpQ/T6...](https://groups.google.com/d/msg/strengthen-
js/ojj3TDxbHpQ/T6bTRDlnEwAJ).

It is very sad that people working on es spec do not care enough about
performance

~~~
hashseed
Yup. To some, performance is just an implementation detail, and they keep
adding hooks like @@hasInstance.

------
npx
I'm really excited about array comprehensions, anyone know if that's actually
going to be part of ES2015? Google kinda gives me mixed messages on this one.

~~~
dkopi
ES2015 was finalized in June 2015. Comprehensions aren't part of it.

If you ask MDN: Was initially in the ECMAScript 6 draft, but got removed in
revision 27 (August 2014). Please see older revisions of ES 6 for
specification semantics.

Non-standard. Do not use! The array comprehensions is non-standard, and it's
unlikely to be added to ECMAScript. For future-facing usages, consider using
Array.prototype.map, Array.prototype.filter, and arrow functions.

Array comprehensions were removed in Babel 6.0

~~~
coroutines
What really pisses me off are the posts about Coffeescript being supplanted by
ES6 like it's a complete substitute. Array comprehensions are just one example
of what JS folks are still missing out on.

~~~
dkopi
List comprehensions are incredible. But they're just syntactic sugar for map()
and filter() and lambdas.

Python's

    
    
      prev = [1,2,3,4]
      next = [x * 2 for x in old]
    

Is the same as javascript's

    
    
      prev = [1,2,3,4];
      next = prev.map(x => x * 2);
    

Python's

    
    
      next = [x for x in prev if x % 2 == 0]
    

is the same as javascript's

    
    
      next = prev.filter(x => x % 2 === 0);
    

And finally, python's

    
    
      next = [x * 2 for x in prev if x % 2 == 0]

is the same as

    
    
      next = prev.filter(x => x % 2 == 0).map(x => x * 2);
    

It could be nice to have a "mapIf" function that accepts a mapping and a
predicate, but I think the extra verbosity makes the above code easier to
understand.

    
    
      next = prev.mapIf(x => x * 2, x => x % 2 == 0);

~~~
coroutines
I think it's important to remember that Array::map() and Array::filter()
construct new Arrays (even if the old one is quickly "lost" and collected).
It's probable v8 sees this and does some trickery to make use of the existing
allocated Array, but I doubt it.

let next = [ 1, 2, 3, 4 ].map(x => x * 2);

versus:

next = (x * 2 for x in [ 1 .. 4 ])

...which becomes:

// Generated by CoffeeScript 1.10.0

(function() { var next, x;

    
    
      next = (function() {
        var i, results;
        results = [];
        for (x = i = 1; i <= 4; x = ++i) {
          results.push(x * 2);
        }
        return results;
      })();
    

}).call(this);

Array::map()/filter() get points for encouraging immutable transformations.

~~~
dkopi
This could probably be solved if Javascript had map/filter/reduce functions
for iterators (and hopefully dictionaries) as well as arrays.

And of course a range(start,stop,step) iterator similar to python's range.

it would then be a matter of:

    
    
      next = range(1,40000).map(x => x * 2);

and because range would be an iterator, the only array created would be next.

------
BinaryBullet
Thanks for the link. I didn't know about Orinoco, and I'm excited about WASM.

...and performance improvements are always good!

------
georgewsinger
Does this have any implications for npm addon authors?

~~~
seeekr
I'll assume that by "npm addon" you're simply referring to plain old npm
packages (native or js). (If not, ignore my comment.)

As far as I know there are currently no big API changes happening in v8, plus
the abstraction layer for native node packages (nan, Native Abstracts for
Node.js) has been, afaik, quite excellent at shielding native package
developers from a lot of potential API breakage -- so generally it can be
expected that there will be either no or very minor implications for native
packages -- and no implications at all for non-native packages since those
work purely with the node API which is not tied to the v8 API.

We'll know more once the v8 project's API changes doc will be updated with 5.1
info, and node core has created its vee-eight-5.1 branch.

EDIT: added clarification about non-native packages; clarity

