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).
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.
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
Does anyone know if any ES2015 features are optimized yet?
When last I checked, just having an unused `let` statement in a function made V8 bail out to the slow compiler, making ES2015 off-limits for anything nontrivial. But that was some months ago.
Thanks! I've updated it to an http link, I'm just so used to https working everywhere nowadays. Maybe it's time to petition GH pages to support letsencrypt!
Wouldn't that either cost money or only secure the connection from the client to cloudflare?
From what I understand (and I admit, my knowledge is pretty lacking around what cloudflare offers) the free part is only the security between the client and cloudflare (and not the security between cloudflare and your server).
On one hand it's better than nothing as I assume most MITMs are on local wifis and such but on the other it gives users a false sense of security.
Then again none of this is of actual concern for node.green
> From what I understand (and I admit, my knowledge is pretty lacking around what cloudflare offers) the free part is only the security between the client and cloudflare (and not the security between cloudflare and your server).
The free plan also supports securing the connection between CloudFlare and your server.
ES2015 TCO is in 5.1 but hidden behind a flag. We are preferring the explicit approach championed by Mozilla and Microsoft (https://github.com/tc39/proposal-ptc-syntax) because it makes the debugging and error analysis story better.
I'm sorry my humble attempt at wordplay mixing the corners bothers you, guys. You are right though, corners are not my forté: failed descriptive geometry back in engineering school.
Proper tail calls are still behind a flag in V8 (including in the 5.2 version in current chrome canary). Is there any indication they'll be turned on by default in node 6?
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)."
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 :)
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.
There will be a polyfill for unsupported browsers. It should be easy to convert most, if not all wasm to asm.js, which can be executed by any browser with typed arrays
Nearly every browser is "evergreen" these days, meaning they auto-update. Chrome, Firefox, and Edge all update often and automatically. Mobile browsers also have this benefit due to being distributed via an app store. This percentage is always going up, but even now is a significant percent (the exact number I'm not sure).
What this means is that web standards can move significantly faster than in the past. Interesting new technologies like WASM can be implemented and tested without waiting 5-6 years anymore. Very exciting to see as a web developer.
I think the question we all should really be asking is how long will it take to get to the point where WASM is practically useful for anything that noticeable chunk of web users cares about.
These days software is mostly auto-updating so at least in the US and other first world countries, relatively soon. The rest of the world is where we'll be lacking. :/
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.
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.
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.
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.
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.
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.
At this point it feels to me, and probably to many other devs and also JS engine implementors, that list comprehensions are such a small improvement over map() and filter() that for now it may simply not be worth introducing another feature into the language when there's already so much being worked on, especially things that will yield much more pronounced improvements to JS language ergonomics with not that much more effort required than for example list comprehensions would take.
(Maybe if we tackle the addition of list comprehensions at a later point, we'll be able to get that neat-o postfix if statement in as well, for a low cost. But I'm just daydreaming (mostly) and speculating (a bit) here!)
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.
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
Including but not limited to: Proper tail recursion (^_^) and destructuring.
Tracked at 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).