WebAssembly is a highly lauded portable code format that holds the promises of making the web run faster while extending the browser to accommodate multiple languages beyond JavaScript. Falling under the jurisdiction of the World Wide Web Consortium, the project has been supported by major browser vendors Apple, Google, Microsoft, and Mozilla. It's now available as a preview in browsers, with a draft specification due this quarter.
But JavaScript founder Brendan Eich, who has been an advocate for WebAssembly, is concerned that conflicting competitive interests might end up splintering the project. InfoWorld Editor at Large Paul Krill recently chatted with Eich, now the CEO of Brave Software, about what's ahead for WebAssembly and JavaScript. Eich also sees a day at some point when his famous creation goes away.
InfoWorld: What is your specific role in the development of WebAssembly?
Eich: At this point, I'm just a member of the JavaScript standards body in a mentor/advisor role. I've known Luke Wagner at Mozilla, [and he] is pretty important to WebAssembly. He did the optimizing asm.js compiler in the Mozilla engine that really showed Microsoft and Apple and even Google that WebAssembly could be the best path forward to fast, safe native code. I know some of the V8 people, and I know some of the ex-Sun HotSpot JVM people at Google who are working on WebAssembly. I'm not doing the work. I'm just looking on, trying to advise and sometimes give feedback.
InfoWorld: So you're an adviser on the project even though you're not specifically developing the code yourself?
Eich: That's right. I would say I'm not an official adviser. I was a sponsor of asm.js and [am] still involved in the JavaScript work and [ECMAScript] TC39, the standards body for JavaScript [that] cares about this separate WebAssembly project over in the W3C community group. As always with the standards work, the principals matter the most, and the principals mostly are paid by the big browser companies or the companies that own a browser. So it's Mozilla, Apple, Google, and Microsoft. It's not me.
I care about this stuff because it needs to go in the right direction. It could fragment, it could fall apart. They have an amazing alliance on WebAssembly, and I view it as fragile because these companies, as often as they cooperate in standards bodies, they compete.
Let's be frank. People will always glad-hand but in their honest moments admit the standards are always based on competitive concerns as well as noble ideas, and these browser companies are quite different from one another. They have different agendas. Apple and Google are not necessarily going to agree on any particular new emerging standard, and yet all four of them announced support for WebAssembly. As it evolves it's very important that you manage it like modern software.
Standards are like software. You can't shoot for the moon and do a big giant project. It's going to take too long and be very hard to estimate how long it will take to do it. And then the risk of these different companies [parting ways] because they don't agree over the long run on the big picture comes up. [Instead] you do it in smaller steps and you get to what people call the MVP -- the minimum viable product. If you study WebAssembly, you'll see that there is exactly that MVP approach. It's roughly co-expressive with asm.js. It has the same power as asm.js. You could even have a program that consults WebAssembly for browsers that don't yet speak WebAssembly but compile a version of asm.js so it would be bigger and slower to learn, but would still be the same program and have the same power.
After the WebAssembly MVP, there's a road map that goes ideally through small steps to a broader, more powerful language that can even be different from JavaScript but still targeting the same single engine in each browser. That's the critical point here about WebAssembly.
WebAssembly is not for a new engine that's different from the JavaScript engine. That was tried by Google with Native Client or Portable Native Client. It was tried with Dart, and it's very costly because having two engines in a browser means now you have more than two problems. The combination of the engines creates new problems with memory management because they can start to have their objects reference each other, and that means you need some kind of common garbage collector or a super garbage collector to collect the cycles [from] between these two engines' memory systems, and that's expensive. There's a lot of history that all points in one direction and that is browsers have a single virtual machine, a JavaScript virtual machine.
But with WebAssembly, it can become addressable by a new source language, and even though it's a binary syntax, it's addressable by a second -- let's call it input language or transport language. That language is WebAssembly, and that can become more powerful than JavaScript over time, and as it does, it should support being a compilation target for other programming languages than C and C++, which is where it's starting.
People are doing WebAssembly as a target language for compilers, definitely for games. They are compiled to asm.js, and as soon as WebAssembly is supported well in browser stable releases, like Chrome Stable, these game companies, they're going to press a button, and instead of getting asm.js out, they'll get WebAssembly out, and at that point you'll see WebAssembly on the web.
If the MVP isn't kept minimal enough or if after they exceed the MVP, which I think is upon us, and they ship it in Chrome Stable and IE and Edge and Firefox and even Safari, which Apple is not committed to, then there's risk that the four companies don't agree on the next step or on the full road map, the ultimate vision for WebAssembly. The risk goes up. I think the discipline needed is that each step you have to minimize by the minimum viable next step, not just minimum viable first step but the minimum viable next step and the next and the next.
InfoWorld: Do you see anything going on that might indicate that the four vendors might splinter and WebAssembly might not happen?
Eich: I don't see it not happening. I've heard from concerned parties inside some of these companies that there is a risk rising after the MVP. Some of the people working on WebAssembly worked on Java in past lives. They have a lot of experience making virtual machines for a programming a language like Java. That is a different vision from the WebAssembly one.
WebAssembly is a second input language to the JavaScript VM, and if you start to assume that all you need is WebAssembly and it's more like a Java virtual machine, you start to make different design decisions. If you jump too far ahead of that belief, you may end up saying, "Well, we don't really need JavaScript anymore." Now, no browser can drop JavaScript support or turn it into a backward-compatibility library on top of a WebAssembly-only engine. Think about that possibility for a minute.
What if you really believe WebAssembly ultimately after some number of years would be the one true way to express executable programs in browsers that was safe and downloadable? If that was true, you might think JavaScript will fade away and at that point if there's any residual JavaScript on the web we can compile it to that ultimate form of WebAssembly. Maybe that happens, but it's so far down the road it's impossible to say that can't happen. But if you try to jump to that too soon, you're going to end up doing work in WebAssembly that will not actually help its adoption and that will not actually be shippable because it will assume that JavaScript isn't important.
I anticipate JavaScript going away some year; I don't know when. It's too far for me to predict. I have no problem with that when the time is right. But the idea that any browser can drop JavaScript tomorrow or next year, or make it be this backward-compatibility path into a WebAssembly-only virtual machine is incredible, it's ludicrous. Chrome has optimized JavaScript. Google's business depends on massive amounts of JavaScript, not only search ads, development ads, email, everything it does. It cares about JavaScript. It can't just press a button and two years from today, we will have everything converted to WebAssembly and we don't need JavaScript.
There's no definite schedule by which they could say that. But the temptation might arise that you want to cut to that far future and not get the true steps to the minimum viable next steps, and if you are not realistic about your prospects, you may make the wrong decision. To make a long story short, I feel there's tension mounting among the vendors, even within these big companies, Google in particular.
Google has a lot of different opinions internally. Some of this is coming out as why don't we just work on WebAssembly as its own thing and maybe JavaScript could be some compatibility layer. Actually, that's really absurd, and I don't think it will work. I think if Chrome did that, it'd get a performance regression on all the JavaScript benchmarks, on all the real-world programs and pages and publishers' content that matters. It would all get slower, and it would [lose] market share to other browsers. I don't think it's a realistic threat, but there's definitely tension because I think some of the people working at the virtual machine level would prefer to work on WebAssembly as its own single input language for a new or a better virtual machine.
InfoWorld: Have there been any technical roadblocks encountered along the way in developing WebAssembly that you're aware of?
Eich: No. It's mostly based on mature stuff around optimizing compilers and virtual machines. Initially, the idea was that it would be based on a binary syntax or what you call syntax trees, parsed trees, abstract syntax trees, but they switched to something more like a stack machine language sort of like Java's current language. That was done under careful evolutionary thinking. There are always trade-offs when you do that. There are these degrees of freedom and even matters of taste and aesthetics. It isn't clear.
Some of the ex-Java people working on WebAssembly may have wanted to do something more like Java anyway, and they had the freedom to do it. In the end it's still another sort of second skin for JavaScript right now, and that's MVP. As it goes beyond the minimum viable product and starts to grow extra power beyond what JavaScript will have, then you get even more degrees of freedom, more choice, and that's where I think the chance of conflict among the vendors and even inside the vendors or at least one of them goes up.
InfoWorld: Do you see a minimal viable product coming out in a few months? Is that what you see happening?
Eich: Yes, I do. I worry that after that, if they don't have the discipline sustainable, the minimum viable next step carefully scoped and managed by requirements and not assuming that JavaScript goes away, that will be the best path forward. Like I said, if you have enough steps over many years, maybe WebAssembly becomes the one true language, and JavaScript sort of fades out as a backward-compatibility layer. But you can't go there from here in one big jump. It does not work. You would take two years out of the market and probably regress performance of all your JavaScript code.
InfoWorld: When do you see WebAssembly reaching a stage where I could program Python in the browser like I can JavaScript or PHP or Java or any other language?
EIch: The road map has that. The road map after the minimum viable product that's coming out soon, has things like when you hook into the garbage collector of the JavaScript host virtual machine, so it's a guest language. The guest language is the Python code that's cross-compiled into WebAssembly. It needs garbage collection, so it should be able to instead of running its own guest garbage collector, which again creates cycle problems with the guest and the host where you can create uncollectable loops and objects. Instead, there should be the one host garbage collector and the guest code should hook into it. It's on the road map, but it needs design with care because it can have pervasive runtime costs.