The WebAssembly team includes people from Google, Microsoft, Mozilla, Apple, and others under the banner of the W3C WebAssembly Community Group.
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?
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.
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.
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.
EE: Could you give us some examples of that?
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.
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.
[Read the Unity Blog post to learn how WebAssembly could dramatically improve the gaming experience.]
“The sky is not falling.”
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?
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?
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?
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.
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.”
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, 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.
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.
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.
“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.
— this is pretty good!”
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.
He spends most of his time in the San Francisco Bay Area with the most beautiful woman in the world.