8 ms·
V8 Release 5.1
- hacker_9 11y ago"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 11y agoY but how long will it take to get to the point where enough users have browsers that support WASM ? 10 years?
- sdegutis 11y agoEven if that's the case, I hope to still be a developer in 10 or 15 years from now, and I'm betting people will still be using the internet then too.
- qaq 11y agoYep just wish things could move along faster :)
- intrasight 11y agoYes we do. But that only happens with technology dictatorships. And we've seen where that leads.
- echeese 11y agoThere 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
- IvanK_net 11y agoIt 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 11y agoOne 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 10y agoWebGL 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.
- wldcordeiro 11y agoThese 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. :/
- mraleph 10y agoI 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.
- SquareWheel 10y agoNearly 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.
- BinaryBullet 11y agoThanks for the link. I didn't know about Orinoco, and I'm excited about WASM. ...and performance improvements are always good!
- inglor 11y agoIn 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 10y agoTo 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
- richdougherty 10y ago:( 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_calls_(tail_call_optimisation) https://kangax.github.io/compat-table/es6/#test-proper_tail_...
- inglor 10y agoOh 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
- westi 11y agoFYI - Your https link generates a cert error because node.green is being served with the www.github.com ssl cert.
- inglor 11y ago
- kingsleymani 11y agoListen to Donald Trump robocall urging California's 'no party preference' voters to register as Republicans. see more here sh.st/IS9mr
- kingsleymani 11y agoListen to Donald Trump robocall urging California's 'no party preference' voters to register as Republicans. see more here sh.st/IS9mr
- kingsleymani 11y agoListen to Donald Trump robocall urging California's 'no party preference' voters to register as Republicans. see more here http://sh.st/IS9mr http://sh.st/IS9mr
- npx 11y agoI'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 11y agoES2015 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 10y agoWhat 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 10y agoList 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);
- seeekr 10y agoThanks 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)
- georgewsinger 11y agoDoes this have any implications for npm addon authors?
- seeekr 10y agoI'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
- Rezo 10y agoWhat'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 10y agohttps://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.
- natorion 10y agoES2015 modules do not take HTML/host environment into consideration. There is still some spec work missing there. See https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/$20Intent$20to$20Implement$3A$20%3Cscript$20type$3D%22module%22%3E/blink-dev/uba6pMr-jec/tXdg6YYPBAAJ https://groups.google.com/a/chromium.org/forum/#!searchin/bl... for more information.
- amelius 10y agoDid they run speed benchmarks against older versions of V8? I'm wondering about the performance cost of these new features (hopefully zero).
- chr1 10y agoUnfortunately it is much larger than zero see https://groups.google.com/d/msg/strengthen-js/ojj3TDxbHpQ/T6bTRDlnEwAJ https://groups.google.com/d/msg/strengthen-js/ojj3TDxbHpQ/T6.... It is very sad that people working on es spec do not care enough about performance
- hashseed 10y agoYup. To some, performance is just an implementation detail, and they keep adding hooks like @@hasInstance.