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

[Anonymous Coward]

Never heard of it. Probably a passing fade. I predict decades more of Javascript and (alas) Flash.

Re:WebAssembly

[ArcadeMan]

Decades more of Flash, eh? Is that the same Flash that I haven't used in over three years now?

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

[Anonymous Coward]

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!

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.

Re:WebAssembly

[Dog-Cow]

You know, you're ignorant. You have no will to be informed. I think that makes it so you should be dead.

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...

[markus]

6502 is a very restrictive architecture. This wasn't too bad, when problems were usually trivial enough that 8 bit operations or at best 16 bit operations were needed the bulk of the time. But for any non-trivial problem these days, that's just not the case. And the limitation of a single general purpose register, a 256 byte zero page, a 256 byte stack and almost no addressing modes is just way too restrictive, if you want to start writing your programs in a high-level language; if you write tiny trivial hand-optimized assembly programs, that might not be obvious.

On top of that, the tiny address space made it impossible to write anything but the most trivial applications (by today's standards).

For simple programs written during that time period, the code was reasonably dense, but certainly not ground breakingly so. If you tried to write any modern programs, you'd be wasting a lot of space emulating 32 bit (or wider) operations, switching memory banks, and figuring out how to work around the lack of an FPU; let alone a MMU. The code would be horribly verbose.

x86 is actually not horribly bad by modern standards. It is almost the most compact encoding that anybody has managed to come up with, and that's a good thing. These days, memory bandwidth is a serious bottle neck and as a first approximation, the more compactly the compiler can encode your program, the faster it'll run. Code density is one of the driving forcing in going from asm.js to WebAssembly. asm.js is intrinsically verbose, but relies on compression to fix this issue.

On the other hand, WebAssembly will have its own dense binary encoding. The encoding is probably not going to look very similar to traditional instruction sets, but instead mimic the internal representations used by compilers and JIT based virtual machines (such as modern JavaScript implementations). It is expected to be very dense, so that even bit web applications load quickly. But as far as I can tell, the binary format hasn't been finalized yet; in fact, I don't think there are any detailed proposals yet. Although that might have changed since I checked a few weeks ago.

Re:Webassembly means...

[cb88]

Javascript doesn't have robust anything....

Re: Webassembly means...

[cb88]

Javascript targets two platforms in practice... x86 variants, and Arm variants. Anything other than that and you are out of luck be it PCC, Sparc, SH, 68k, AVR, PCI whatever.... At least with webassembly there is hope that anything LLVM can target webassembly will be able to target with minimal effort.

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

[phantomfive]

Javascript has features that make it difficult to optimize and compile (like the ability to create new functions from code at runtime, or the fact that every variable is an associative array).
WebAssembly is a reduced-functionality version of Javascript that allows better optimization. That is the purpose.

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.

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

[Daniel Hoffmann]

V8 actually has two JIT compillation modes exactly because of things like this. One handles "easy" functions and the other handles "hard" functions (functions that contain eval or try and catch for example), the "easy" compiller has worse performance. This link explains it well:

https://github.com/petkaantono...

Great read for people who want to optimize for V8, many of the tips should be valid for other javascript engines as well.

From the article:

Currently not optimizable (ie will use the slower compilation method):
Generator functions
Functions that contain a for-of statement
Functions that contain a try-catch statement
Functions that contain a try-finally statement
Functions that contain a compound let assignment
Functions that contain a compound const assignment
Functions that contain object literals that contain __proto__ , or get or set declarations.

Likely never optimizable:
Functions that contain a debugger statement
Functions that call literally eval()
Functions that contain a with statement

TypeScript

[innerpeace]

Google and MS are teaming up on this and it will be in AngularJS 2. With that kind of weight behind it, I'd bank on it being the next JS replacement/supplement.

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.

Emscripten

[tepples]

What does matter is that it may open up the development of software for execution inside a browser to a wider variety of languages

That already existed: Emscripten compiles any language with an LLVM front-end, such as Clang++, to asm.js. Apparently one of the goals of WebAssembly is to make Emscripten more practical.

Web Workers

[tepples]

Hello, it's 2015, where's my MULTIFUCKINGTHREADING?

What problems have you run into with Web Workers?

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.

Easy answer:

[Qbertino]

Find a feasible FOSS replacement for Flash that enables fast and easy cross-plattform development for performant non-trivial 'good-looking' client applications - and you have a winner. Offer some tacky half-assed JS cross-compiler nonsense, and your new tech won't get off the ground. The Web and DOM tech is a mess enough as it is, without yet another PL/runtime solution thrown into the mix.

However, I remain slightly optimistic that this may be the long awaited not-fucked-up-by-adobe FOSS Flash successor we've been waiting for. All other non-foss contenders failed throughout the last 15 years, but this might have a chance, also since there is nothing else around and the web has taken over as platform of choice due to 80ies style tech fragmentation via the mobile revolution.

Two cents from a senior webdev.