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?

Comments

Webassembly means...

[__aaclcg7560]

I can learn assembly language! On the web, no less!

Re:Webassembly means...

[markus]

You can write asm.js by hand, no so sure about WebAssembly, although there could be rare corner cases where this is warranted.

But in almost all cases this is not the expected deployment scenario. Rather, you'll write your web app in one of many different high-level languages, and it will get compiled to WebAssembly. Interestingly enough, one of these languages is C++, which has a vastly different thread and memory model compared to JavaScript. This has always been a big stumbling block as there is existing C++ code that people would like to run in browsers, but up to now there was no good solution that works across browsers.

The roadmap suggests that JavaScript will retain its robust memory and thread model, but gain enough features to support the less robust but higher-performant model used by C++. We truly live in interesting times.

This will also address the problem that JavaScript could never effectively take advantage of multiple cores, but CPUs tend to add more performance by adding cores rather than by improving single-thread throughput.

Re:Webassembly means...

[PPH]

There's a book out already.

Re:Webassembly means...

[cb88]

Javascript doesn't have robust anything....

I don't think it will gain much traction

[msobkow]

One of the big "security benefits" I've heard claimed is that WebAssembly will only be able to invoke the same functions/methods as JavaScript itself. So that implies that WebAssembly is nothing more than pre-compiled JavaScript.

As the compile phase of JavaScript pales in comparison to the execution phase, the only people I can see pushing for this are those who want DRM-style protection of their JavaScript so no one else can read it.

Re:I don't think it will gain much traction

[markus]

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.

Re:I don't think it will gain much traction

[markus]

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.

WebAssembly (and asm.js) solved the boot strapping

[markus]

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.

Different languages

[wrmrxxx]

JavaScript execution speed is not the important thing about WebAssembly. What does matter is that it may open up the development of software for execution inside a browser to a wider variety of languages, almost all of which are likely to be better than JavaScript in one way or another.

Re:Different languages

[markus]

JavaScript isn't necessarily such a bad language; otherwise, we wouldn't see Node.js gaining so much popularity.

But you are of course right, that there isn't a one-size-fits-all language, and there are plenty of problems that can better be solved in other languages. Allowing more choice of languages for web apps is a good thing.

Also, some of the more advanced JavaScript features that are in the pipeline (or starting to be deployed) are really cumbersome to program manually. All the work that will allow implementing pthreads in JavaScript is really low-level. It'll be nice to have compilers that target these features.

Re:Different languages

[weilawei]

JavaScript isn't necessarily such a bad language; otherwise, we wouldn't see Node.js gaining so much popularity.

Bandwagon appeal. With your UID, you ought to know better. Provide a technical argument and/or step away from the keyboard until you've thought it over. Note that I'm not saying there isn't a good reason--only that your given argument is crap.

Oh look, another dice clickbait

[tiagosousa]

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.

Re:WebAssembly

[narcc]

Here's something you might not know: Your personal use case is not representative of the world at large.

Flash is still quite popular, and isn't likely to vanish any time soon. Millions upon millions of users engage with flash content on the web daily. It's going to take a very long time for alternatives to catch-up in terms of authoring tools and, most importantly, content. It'll take even longer for that old content to fade into obscurity -- just like Java applets before it.

I know it's cool to play the ideologue, but it's foolish to deny the obvious reality. Flash is going to be with us for many years.

Re:WebAssembly

[narcc]

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.

Re:WebAssembly

[TheRaven64]

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.