V8 Release 5.1
v8project.blogspot.com
v8project.blogspot.com
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).
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
I made my blog hosted on Github HTTPS with this, mainly so that I can experiment some features like Service Workers.
The free plan also supports securing the connection between CloudFlare and your server.
Any info on when it is going to come out of that corner?
Also, the fate for tail-call-elimination is pretty uncertain at the moment; see: https://github.com/tc39/proposal-ptc-syntax
As far as I can see WebKit/Safari is the only major browser that has an implementation: https://kangax.github.io/compat-table/es6/#test-proper_tail_...
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
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.
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.
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.
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.
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.
See https://groups.google.com/a/chromium.org/forum/#!searchin/bl... for more information.
I'm wondering about the performance cost of these new features (hopefully zero).
It is very sad that people working on es spec do not care enough about performance
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
Python's
prev = [1,2,3,4]
next = [x * 2 for x in old]
prev = [1,2,3,4];
next = prev.map(x => x * 2);
next = [x for x in prev if x % 2 == 0]
next = prev.filter(x => x % 2 === 0);
next = [x * 2 for x in prev if x % 2 == 0] next = prev.filter(x => x % 2 == 0).map(x => x * 2);
next = prev.mapIf(x => x * 2, x => x % 2 == 0);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!)
(Edit: formatting)
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;
})();
Array::map()/filter() get points for encouraging immutable transformations.
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); [x + y for x in [1,4,9] for y in [2,4,6] if x < y]...and performance improvements are always good!
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