Did they run speed benchmarks against older versions of V8?
I'm wondering about the performance cost of these new features (hopefully zero).
V8 Release 5.1
41–50 of 62 posts
Re: V8 Release 5.1
#42Earlier quoted context omitted.
Yeah, the free version is HTTPS only between client and CF. I made my blog hosted on Github HTTPS with this, mainly so that I can experiment some features like Service Workers.
Source? Last time I used it you could encrypt both hops (although you obviously need to tell CF to ignore the cert mismatch for backend server).
They are both encrypted but since you can't verify the "server" certificate it is vulnerable to MITM.
Re: V8 Release 5.1
#43In 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 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).
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.
Re: V8 Release 5.1
#44In 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 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. Also, the fate for tail-call-elimination is pretty uncertain at the moment; see: https://github.com/tc39/proposal-ptc-syntax
:( I was looking forward to tail calls.
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_...
Re: V8 Release 5.1
#45Earlier quoted context omitted.
>In case anyone is wondering, NodeJS v6 is right around the corner with V8 5.x. Any info on when it is going to come out of that corner?
The plan is for a Node.js 6.0 release on Tuesday: https://github.com/nodejs/node/issues/5766#issuecomment-1983... . This would include V8 5.0.
Wow, that's soon, thanks!
Re: V8 Release 5.1
#46In 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 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).
And by 2018 node will be as fast as php with 1,000 new features :)
Re: V8 Release 5.1
#47Earlier quoted context omitted.
For some reason the mismatched usage of 'corner' really bothers me! I'm sorry for this pointless comment.
I was about to saw the same thing. That phrase must be so confusing for maga if he always pictures an interior corner instead of an exterior one.
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.
Re: V8 Release 5.1
#48I'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.pro…
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.
Re: V8 Release 5.1
#49Earlier quoted context omitted.
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.pro…
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]
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);Re: V8 Release 5.1
#50Earlier quoted context omitted.
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…
Thanks for taking the time to type this out.
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)