Slashdot Mirror
WebAssembly and the Future of JavaScript
Nerval's Lobster writes: WebAssembly is the next stage in the evolution of client-side scripting. In theory, it will improve on JavaScript's speed. That's not to say that JavaScript is a slowpoke: Incremental speed improvements have included the rollout of asm.js (an optimized subset) in 2013. But WebAssembly—while not a replacement for JavaScript—is intended as a "cure" for a variety of issues where JavaScript isn't always a perfect fit, including video editing, encryption, peer-to-peer, and more. (Here's a full list of the Web applications that WebAssembly could maybe improve.) If WebAssembly is not there to replace JavaScript but to complement it, the key to the integration rests with the DOM and Garbage Collected Objects such as JavaScript strings, functions (as callable closures), Typed Arrays and Typed objects. The bigger question is, will WebAssembly actually become something big, or is it ultimately doomed to suffer the fate of other hyped JavaScript-related platforms such as Dart (a Google-only venture), which attracted buzz ahead of a Minimum Viable Product release, only to quickly fade away afterward?
Previous attempts at replacing JavaScript always suffered from a boot strapping problem. While there are only a small number of major desktop browsers, overall, there are actually a lot of different minor browsers that people expect to work. And even among the desktop browsers, not everybody always runs the most recent release.
Content producers don't really like writing content that only 30% of their users can view. So, unless a new technology is rolled out to 90+% of the deployed browsers, nobody is going to write content for it. On the other hand, if nobody writes content, the rest of the browser manufacturers won't put any resources into adding support for the new technology.
Both asm.js and WebAssembly have a fallback mode that uses plain JavaScript, as available in virtually 100% of all browsers. Performance will obviously be degraded, but that's much better than making the content completely inaccessible. And users are more likely to upgrade their browsers, if they can see a low-fidelity version of the content and know by switching to a newer browser they'll get the high-fidelity version. So, unlike the previous scenario, this is actually a virtuous circle.
An awful lot of work has gone into making JavaScript virtual machines both high-performance and super secure. This is a difficult thing to get right. It is good to see that this work can now be leveraged for other languages, rather than forcing browser manufacturers to redo the work for each and every language. In the process they'd inevitably get something wrong, and that's quite dangerous; insecure browsers mean compromised computers.
Might as well read an interview with the man behind webassembly. Found it extremely informative and I'm looking forward to a future where all major browsers support first-class alternatives to javascript through webassembly.
That is possibly true, although details will still need to be seen. asm.js programs typically allocate a single static memory region that they than manage themselves without bothering the JavaScript VM to track memory references. In fact, a asm.js program doesn't have access to garbage collected objects. As soon as it tries to access those, it falls back to JavaScript mode (every asm.js program is by definition also a valid JavaScript program, but not necessarily vice versa).
WebAssembly programs at least originally will do the same as asm.js. It is possible that as more experienced is gained with this feature, there will be a way for WebAssembly to tap into the garbage collected pool of objects. Only time will tell.
iOS actually sees relatively little use. Yes, selling a comparatively small number of rather expensive phones and tablets does give Apple some impressive revenue numbers, but the proportion of iOS users is very small. There are many more users using cheaper Android devices from a wide variety of manufacturers.
Look at these recent browser usage stats, for example. iOS Safari is only about 7%. The old Android browser is still at over 5%, plus there's Chrome for Android at over 13%, and UC Browser for Android is over 5%, and even the failed Firefox for Android is at 0.14%.
All of the mobile usage together still pales in comparison to desktop browser usage, even many years after mobile devices were alleged to have "killed" desktop and notebook markets. The number of people using Chrome 43 on non-mobile systems almost exceeds the total number of mobile users, across all platforms!
Flash doesn't run on iOS, so it's already on the way out.
So said everyone ... 7 years ago. At this point, it's just pure delusion. iOS just isn't relevant.
The "major decline" you and everyone else has been on about nearly a decade just hasn't happened. Flash has declined, sure, but not significantly. Google and Mozilla recognize this, and have taken steps to ensure flash content will work in their browsers for the foreseeable future. After all, if their browser can't render the content people want, they'll look elsewhere.
I suspect we'll have this exact same discussion 5 years from now. There's just too much content and the alternatives just aren't mature enough to see any significant change over the next few years.
This is simply reality.
Required reading for internet skeptics
Why would you have heard of it? I've heard of it as a compiler writer, because the WebAssembly back end is currently being merged into LLVM, which will make it possible for all languages that LLVM can target to emit WebAssembly. It's basically the successor to PNaCl (heard of that?), but this time with cross-industry backing. Backers include Google, Microsoft, Mozilla, and Apple - that gives it a pretty good chance of appearing in all of the major browsers.
I am TheRaven on Soylent News