Why we Need WebAssembly
An Interview with Brendan Eich
Brendan Eich & Eric Elliott Discuss WebAssembly Details & Misconceptions
Last week (June 17th, 2015), Brendan Eich announced a new project to bring new low level primitives to the web — a move that will make it easier to compile projects written in languages like C & C++ to run in browsers and other JavaScript environments. If this is your first time hearing about it, read “What is WebAssembly” for a basic overview.
The WebAssembly team includes people from Google, Microsoft, Mozilla, Apple, and others under the banner of the W3C WebAssembly Community Group.
The announcement left the web development community speculating about how WebAssembly might impact the future of JavaScript. Brendan Eich fills in the gaps in an interview with Eric Elliott.
TL;DR: No Chicken Little, the sky is not falling.
All emphasis added.
EE: Recently, you announced on your blog that we’re getting something called WebAssembly. Basically an assembly language for the web, a low-level compile target. Can you tell us what that’s about, and what motivated you to work on it?
BE: Sure. This is in some ways just a continued process that started with ASM.js. ASM.js is a subset of JavaScript that has no objects and has no garbage collection or just in time compiler pauses. It’s a target for C/C++ — a statically typed subset of JavaScript. This was demonstrated at Mozilla in partnership with the big gaming companies like Epic Games with Unreal Engine and Unity with the Unity engine and IDE.
So that allowed a lot of games published with those engines — games out there in the market with Unreal Engine 3 and Unreal Engine 4, games built on Unity 5 to target JavaScript with just another instruction set.
These games would be possibly targeting PS4, XBox and PC. Now they could also be targeted at the web with WebGL and ASM.js, web audio and other APIs are important, gamepad APIs, full screen APIs all matter.
That was a big success story at Mozilla when I was there and they actually crossed over to Microsoft. I remember talking a couple years ago to Anders Hejlsberg and Steve Lucco. Anders of course who did C# and .NET and Steve who led the Chakra team — still does, I think. They were pretty enthusiastic about it, and so it came to pass that Edge supports ASM.js as an online optimized, whole module optimization just like Mozilla does, with good performance.
To put a not too fine a point on it, I think this was the last straw for Native Client, or really Portable Native Client (PNaCl) which was the only way Google was going to get their version of the compile to safe native story going for C & C++ in browsers, and that was never even fully enabled in Chrome. It was whitelisted for certain Google properties. I think Google+ had an image editor.
As time went on, the fully native client wasn’t going to cross to other browsers. It was a long road to do everything they intended to do. They were pretty ambitious. Whereas ASM.js started out looking like, oh, it doesn’t have threads, it doesn’t have locks, it doesn’t have a lot of things they need in native code, it doesn’t have SIMD (single instruction, multiple data), short vector intrinsics for vector units that are built into our modern CPUs.
Sure enough, JavaScript didn’t have those things but now it’s getting those things. SIMD is in Firefox nightly, it’s coming to V8, and Intel’s already done an implementation in their version of V8, Crosswalk, and Microsoft announced SIMD support coming to Chakra.
Assuming stasis on the web — it’s not a good assumption, I think that was the mistake that happened long ago with projects like Portable Native Client and Dart, too. They assumed JavaScript was just incompetent, it could not get any better and therefore they had to do something that amounted to a whole second system, or third system to be added to browsers, and yet they couldn’t get it fully into Chrome.
I’m not gloating here. Realism requires incrementalism. All browsers must move in smaller steps. This is really a place where Firefox and Chrome restored browser competition — Firefox first. Certainly there are alternative worlds, we saw one in the early 2000's with IE reaching 95% market share and Microsoft not investing in the web, instead investing in .NET and Windows Presentation Foundation, all that stuff.
Anyway to not go on about history, the continued evolution of ASM.js is wasm. The reason it’s important is because once ASM.js crossed over into other browsers, it became clear that it was gonna cross over into all the browsers.
Yet JavaScript and even ASM.js, a subset of JavaScript, is missing SIMD, threads, shared memory and other primitives. Even with ASM.js, you’re still parsing JavaScript. It’s a subset. You might run a dedicated parser for that subset, which is another maintenance chore because now you’ve got two parsers, one for the full JavaScript language and one for the subset.
You’re still faced with a costly parsing problem compared to what could be done with a more efficient, compressed abstract syntax tree (AST), which is what WebAssembly is aiming at.
People have been asking for bytecode on the web, thinking that they want Java bytecode. What I think the researchers at MSR and other places have shown is that they don’t want that — that bit back hard in several ways. AST encoding is much better.
At first, WebAssembly starts out just like ASM.js, but with a compressed syntax, that’s a binary syntax. But once all the browsers support both wasm and ASM.js, and after a decent interval of browser updates, then wasm can start to grow extra semantics that need not be put into JavaScript.
They may in fact be put into both JavaScript and wasm because it’s the same one engine (1vm), but there are certain things we might not want to ever put into JavaScript that could be put into wasm for the benefit of other languages like C++ or Haskell. There are lots of languages you might compile to wasm.
EE: Could you give us some examples of that?
BE: Sure, this is all written up in the GitHub but just arguing for shared memory array buffers to get multi-threaded games cross-compiled was a stress on JavaScript because for the longest time we didn’t want race conditions in JavaScript — it’s always a fragile process with bug hazards. That’s an example of something we might have just kept in WebAssembly if we had that choice.
Down the road there are things like that, like zero cost exceptions might not make sense in JavaScript. They require some compiler and runtime cleverness, but they do make sense for C++, and Swift.
Another example is call/cc (call-with-current-continuation). Call/cc is too powerful a tool. It has challenges for JavaScript engines in implementation and security hazards.
You have these non-local functional gotos. You can call a continuation and be off in a different stack. So it’s not like the local, limited continuations like we have in generators in ES6. It’s a deeper continuation. So call/cc could be put into wasm, into the engine that handles both wasm and JavaScript down the road. It’s conceivable. It won’t go to the JavaScript language but to the WebAssembly syntax in a way that won’t affect the legacy JavaScript world.
EE: Speaking of which, are there security implications to wasm that we need to think carefully about?
BE: As it starts as co-expressive with ASM.js, it doesn’t add any new security issues right out of the gate, but as it starts to diverge a year or two down the road, then yes, we need to look at the security properties of all those extensions. That’s an added challenge. That’s something that the native client folks at Google have been thinking of a lot. They’re helping and their knowledge in this area is helpful.
We’re trying to chase undefined behavior out of C++ and the LLVM compiler that PNaCl (Portable Native Client) uses, and Emscripten also uses. From the hardware up to the specification for C++, there’s a lot of undefined behavior, and that’s not good for security.
JavaScript has been a lot more prescriptive and is trying to be safer than a lot of other languages. For WebAssembly we need to go more to the JavaScript side.
EE: There was an interesting headline in the register. Are you trying to KILL JavaScript? Is that what this is all about?
BE: [laughs] No. I’m a pragmatist. I’m an old C/C++ hacker. This is all a big system that evolves. Humans trying things, but also facing real compatibility constraints on the web.
You don’t break the web, you don’t get to clean the slate and start over. Anybody who tries is going to fail. Even when you look at native apps on mobile devices, where there are fairly mature native languages and toolkits for user interface and graphics, there’s still a lot of web. There’s a lot of hybrid apps.
Facebook still uses web views. All the big apps — Amazon, Pinterest, and so on use web views. There’s a lot of web assets that would be completely insane to reinvent with native presentation layers instead of HTML. So the web is still pretty darn important. It’s also the highest monetization platform.
Smartphones have incredible penetration. There will be a smartphone for almost every adult on the planet within a few years, and that’s gonna be huge for many things, but that doesn’t really mean a smartphone’s a PC. It’s still more of a consumption device. It’s not like you’re sitting and typing and researching and shopping in depth.
So rather than kill JavaScript, which is not feasible, what I’m trying to do is respond to real engineering problems that we’ve had with ASM.js. Loading a big game from Epic or Unity can take 20 - 30 seconds. That’s too long. With a compressed abstract syntax tree encoding that’s 20 times faster, just a couple seconds, that’s what you want. So there’s a real reason for wasm, and it is a valid reason.
[Read the Unity Blog post to learn how WebAssembly could dramatically improve the gaming experience.]
Wasm helps JS win, it is a win not only for native code compilation. Eventually all the browsers and webviews will support wasm syntax to serve the compile target master and free JavaScript so it can serve the JavaScript master.
JavaScript has been in that house divided stage, and it never works in the long run. Like I said, even the shared array buffer extension, that’s a bit of a stretch for JavaScript, and having the ability down the road to let wasm do the exotic things that C++ wants and not needing to figure out ways to put those less-safe facilities into JavaScript is a great relief.
So, parsing performance, and not serving two masters, those are good reasons to do wasm. We’re not killing JavaScript. I don’t think it’s even possible to kill JavaScript.
“The sky is not falling.”
EE: That’s good news for a lot of people who have been a little bit worried about that. In fact, I think that was the most common response I saw on the internet to the wasm announcement. People were afraid that the sky is falling. I think we can safely say that the sky is not falling, and that JavaScript will stick around for a while.
BE: I think given the privileged position JavaScript has, and how wasm is really starting out as a target for static languages like C++, it’s gonna be a while before we get other future extensions to wasm like garbage collection and just-in-time compile to wasm, features we need for dynamic languages to perform well, that’s gonna take a while to do, too.
In the meantime, people at Google doing the Dart compiler, they’re gonna stick with JavaScript because when you aren’t compiling in checked mode, Dart code is really dynamic code — it needs JavaScript’s JITs (Just In Time compiles). It needs polymorphic inline cache and other optimizations.
Ideally we’ll get things in JavaScript like big integers/bignums that Dart has that JavaScript doesn’t yet, which is on the agenda for future ECMAScript. I think JavaScript’s gonna be around as long as that. It’s really hard to say at any point that we can get rid of JavaScript as the built in and the only built in high-level language in browsers.
EE: Back in the 90's, I used to write a lot of C/C++ myself. I grew up in the demoscene. I don’t know if you’re familiar, but we basically built art applications, like a movie that’s running live code instead of prerecorded video. Back then we used to drop into assembly language all the time to do things like video processing or audio processing, or effects like that where there’s a lot of data crunching. Do you see wasm as a useful tool for people building those kinds of applications?
BE: I do. I should mention that we have SIMD coming to JavaScript. We’ve already had WebGL going back almost 10 years now. Vladimir Vukićević at Mozilla started out doing it in and it went into the Khronos Group, and it’s great to have WebGL as part of the foundation that supports the big games from Epic, Unity, and others.
However it’s only based on OpenGL ES, the Mobile profile of OpenGL. It’s only just been uplifted from OpenGL ES2 to 3 point something in WebGL 2. So when you look at desktop GPUs, they can do a lot more. Wasm could have OpenGL 4, the latest and greatest desktop with all the fancy extra shaders and target all the insane Nvidia GPUs that are out there.
And maybe those GPUs will trickle down into mobile devices, but it’ll take a while. Whatever happens with WebGL, with wasm we have an option over the next few years to do even more to-the-metal programming, including those advanced GPUs.
EE: Who’s involved in this? I know you’ve mentioned in your blog that people from Microsoft and Google, who all is involved, and where are we gonna see support coming from?
BE: It’s hard for me since I’m an outsider to make announcements for other companies, and you may have noticed, one company couldn’t quite get its name lent, but it was only a matter of the usual protocol delays. There was no hardship there, and the principal there who works on WebKit and JavaScriptCore, Filip Pizlo whose name is obviously active in the GitHub repositories (the WebAssembly GitHub account).
Filip works for Apple. The other companies that did name themselves are Microsoft, Mozilla, and Google.
Mozilla really pioneered this with ASM.js, but the Google folks on PNaCl had also been solving a lot of the same problems and wringing out undefined behavior, thinking about more advanced features that ASM.js doesn’t currently support like dynamic linking and threads before we got around to doing the shared array buffer.
I think at some point it was time to heal the rift. I think on Hacker News a lot of people think I’m a big jerk because somehow from my throne of skulls at Mozilla I manage to mentally control everybody in the industry to stop PNaCl from coming to other browsers, or that if I’d just put it into Mozilla (at great cost) then everybody else would get in line because if Mozilla and Google do something, everybody else must do it. Not so, see WebM.
So there I think there are a lot of hard feelings from people who are not facing reality. The fact is PNaCl is not gonna go cross-browser, but a lot of the work was LLVM based. It was getting ahead of what we did with ASM.js, so it’s the perfect marriage now. It was originally considered ill-starred, but it’s actually turning out great to have people working on WebAssembly who used to work on ASM.js and PNaCl.
EE: Given all the support behind it, when can we expect to start seeing built-in browser support for wasm?
BE: I don’t know, they still have to build a prototype or something that can evolve, because one of the things we learned with JavaScript, and HTML for that matter is you don’t get to do a lot of hard versions. You end up floating something that has object detection or feature detection, or some autoconf testing facility so that you can write code defensively to degrade gracefully.
So that if, in a few years when wasm 2018 has call/cc in it, maybe some other languages are just out of luck, but if it also has some advanced feature like zero cost exceptions, you want to run on a browser with wasm 2017 without zero cost exceptions, maybe you just take a greater hit for your exception calls. Maybe that’s OK.
There’s going to be something very important from JavaScript programming we’ve dubbed 1JS which is for mimetype versioning that we were using for ES4 about 8 years ago. It is codified in RFC 4329 Bjoern Hoehrmann’s writeup of the `<script type=”application/ecmascript”>` for JavaScript. He says there’s a version parameter. It doesn’t say what the values of the version are, (but you can’t ignore it), but people are always gonna get versions wrong, and mimetypes wrong or write script tags without any mimetype.
This whole idea of version locking failed and rightly so, and I think it’s been a problem in general in other runtime systems that tried it. What I expect will happen is in the next few months, they’ll get to a point where they’re happy with the abstract syntax tree encoding performance, with the trade-off between encode efficiency and decode efficiency, where decode is most important. They’ll have a good idea of how to extend the syntax.
Then they can start shipping it in nightlies. I would expect sometime — I would think by next year — but this is totally a guess, right, I don’t have a crystal ball. But we’ll start seeing at least nightly browsers have wasm support maybe even sooner, it could be this fall.
“I would think by next year —
but this is totally a guess.”
Soon enough, the community group will start thinking about standardizing the syntax. The one thing that makes this even less of a pressing issue is that there’s already what they call a polyfill — it’s really just a library — a JavaScript version of a decoder for the prototype abstract syntaxt tree that goes from that binary code back to ASM.js.
Even now JavaScript has sort of soft-launched wasm without having to commit to the exact syntax. The key with web standards as always in the modern HTML5 era is to iterate, not to try to do some giant 10 year spec and get it all right instantly, and any time that seemed to happen like with ES4, which was a big refactor, or ES6 which was large, the only thing that saved it was the incremental prototype that was going on in the real engines.
HTML5 had this patina of being a big, multi-year version that ended with a giant version stamp 5, but in fact it was already rolling out the parts years before anybody said it was done.
EE: You mentioned a prototype, is that something that people can download and play with and take a look at right now?
BE: Yeah, I believe so, if you go to the GitHub account, WebAssembly and you look under polyfill-prototype-1 you’ll see a decoder. I haven’t had any time but if you look at Emscripten — Emscripten is going to support this with an optional mode using the polyfill, the library JavaScript decoder, and that I think is already being experimented right now.
EE: As all these things come into wasm, is JavaScript still gonna see some of the low-level features that you talked about in your talk, “Taking the High Road and the Low Road”?
BE: Yeah, like I said, wasm down the road when it’s supported and you don’t need the polyfill, then it can be safely more expressive than ASM.js. It can have bigger semantics, however, that’ll be a while.
In the meantime a lot of stuff has to go into JavaScript anyway because people want it even if they’re not compiling. They want it for hand-coding. This is true of SIMD, this is true of a lot of the stuff that we’ve been uplifting the `Math` object for, intrinsics, things that you might get in libm if you were in C code or C++ code, there are some things that ES6 added and there are a few more things on our agenda, still.
I think we’ll still take the low road as well as the high road, but I think in maybe 5 years’ time frame, we wouldn’t have to sweat it so much, and if there was something that was low-road that was only for compilers and we’re pretty sure wouldn’t be needed by JavaScript hand coders, then we could leave it out of JavaScript, and that’s part of not serving two masters.
EE: Do you think this is gonna cause a lot of language fragmentation, or is it diversity, and what’s difference? Is this a good thing or a bad thing? A lot of people seem to be confused about that.
BE: I think that JavaScript’s got the unique dynamic language built into the browser status, but wasm can support many compiled languages, certainly the static ones right now — particularly the ones that use LLVM. Microsoft has their own compiler so they’ll be doing wasm from a different compiler framework, but that’s great. The more, the merrier.
Certainly GCC or similar could generate wasm, but I think to get to the dynamic languages, like I mentioned Dart, or Ruby, or Python, even JavaScript — that’s gonna require some extensions that I mentioned earlier, like: garbage collection hooks, JIT support, things like that. Otherwise they just won’t be competitive.
There’s good precedent. The JVM grew over many years, thanks to John Rose grew things like `invokedynamic` and other hooks for just in time compilation optimizations like polymorphic inline caching so the JVM is actually a credible dynamic language platform.
All of these runtimes have become polyglot VMs — JavaScript VMs. Java hasn’t died just because the JVM now supports Clojure, and Scala, and other languages. We’re almost at the second golden age of programming languages, you know, take Rust, Haskell, Idris, and other languages.
The more the merrier, I say. It’s not gonna become the tower of Babel because I think JavaScript will be the lingua franca of the browser, today and tomorrow. If you’re writing front-end code or really anything that’s not on the critical path when you profile.
“The more the merrier, I say.”
But if you really wanna map those intense 3d games, or some really complicated computer vision kernel algorithm, then you might reach for C++ or something that compiles to wasm, and in five years, if people are enthusiastic about some new language that compiles to wasm, then that language should rise, and I don’t think that’s a problem, I think that’s just a part of life in the big city.
EE: So you do eventually want to see JavaScript get killed off if something better comes along?
BE: Again, I don’t foresee how it can be killed off because all the content on the web has to run within the browsers and a JavaScript runtime implemented in wasm would be a real challenge to engineer to be just as fast as V8 is. But many many years down the road, if someone did that, then you could just make JavaScript one of n wasm implemented languages.
“Hey this isn’t the JavaScript I remember
— this is pretty good!”
But it’d still be this language that has such a great foothold on the web. And it also has evolved because we’re still working on making JavaScript a better language for hand-coders, so it’s not sitting still. ES6 has people saying, “hey this isn’t the JavaScript I remember — this is pretty good!”
Again, have no crystal ball, I just think it would be very hard to kill JavaScript. I’m not trying to kill JavaScript. I have no particular need to see JavaScript live any longer than it needs to, and if people find other languages better in the long run, and if down the road, we go through so many iterations that it doesn’t matter that it’s JavaScript built into the browser, then I say, “que sera sera.”
I really think that people who want JavaScript to fail because they’re hostile to it for some reason or other are gonna be disappointed. It’s not going away.
This is actually good for both JavaScript and other languages. Don’t assume stasis. I think wasm will grow to include lots and lots of expressiveness for lots and lots of languages, JavaScript included.
This is one of those instances where everybody can win. That really fits everybody’s wishlist for the web, whether it’s Apple, or Google, or Microsoft, or Mozilla.
The thing to do now is to focus on incremental improvements, not to try to get too far ahead of reality. Things like ES4, or PNaCl or Dart, or XHTML back in its day. All these big bangs that try to remake the web in its own grand planned fashion do not work.
So now that we have all these people cooperating on these little bangs, we should see a series of little bangs that have great cumulative effect.
/be
Eric Elliott is the author of “Programming JavaScript Applications” (O’Reilly), and “Learn JavaScript Universal App Development with Node, ES6, & React”. He has contributed to software experiences for Adobe Systems, Zumba Fitness,The Wall Street Journal, ESPN, BBC, and top recording artists including Usher,Frank Ocean, Metallica, and many more.
He spends most of his time in the San Francisco Bay Area with the most beautiful woman in the world.
