DFINITY  >  Press & Media  >  What is WebAssembly?

What is WebAssembly?

WebAssembly (WASM) is the first standard for software that runs anywhere. This is a series of interviews with Andreas Rossberg (co-designer of WASM, DFINITY), Ben Tizer (WASM Team Technical Lead, Google), and Bradley Nelson (Chair of W3C WASM Working Group, Google)

WebAssembly is a portable low level software development standard designed to replace Javascript. Beyond the browser, WebAssembly is a system that allows software to be written once and run on all common hardware platforms, making it possible to eliminate the siloing of applications on specific platforms - IOS, Android, Windows, Mac.

WebAssembly is also designed in such a way that makes it perfect for programming blockchain applications. It is also part of the execution layer of the DFINITY platform.

BEN TITZER

WebAssembly is a portable, low-level language, which is a compiler target for other languages. It's designed to be portable, it's designed to be fast and it's designed to be low-level. Low-level in the sense that it doesn't make particular prescriptive choices about high-level features, so that is something that would be compiled away from a high-level language, because it's a low-level language that it makes it universal. It's designed to be portable in the sense that you can run on many different machines. Even though it's low level, it's in the middle because you can compile many languages to it and you can run it on many different machines.

BRADLEY NELSON

WebAssembly is a portable, low-level format for the web. I think that the most important attribute with WebAssembly is that we're using what hardware is actually good at as sort of a guiding light.

ANDREAS ROSSBER

Initially, the motivation for WebAssembly was to broaden the range of things you can do on the web platform. The web platform evolved over 20 years, 25 years from just like a very simplistic document, hypertext, a language that was incrementally extended with various things not always in the most structured manner, but it still kind of has this heritage that you have HTML which just describes documents, and on top of that you have JavaScript with which you can describe more dynamic content, but it's all still in this kind of model which is different from how you would develop applications in other domains. In particular, the only programming language you can use on the web as JavaScript. JavaScript had a stranglehold on the web and to some extent, so one motivation for WebAssembly was to break free from the stranglehold, unlock certain things that you can't do in JavaScript or with the way the web is currently set up, like performance being one thing, but also allowing other programming languages, other paradigms to program the web which might make it easier to develop certain kinds of applications than JavaScript could ever do. You can see as a progression of prior technologies that happened on the web that different companies tried like Google did Native Client, which was an attempt to bring native machine code to the web. While Mozilla did something called asm.js which was another attempt to define a variant of JavaScript that can also be translated in a very efficient manner to have code run fast on the web. WebAssembly is a followup of both of these technologies, both of these have converged into WebAssembly. People who have previously worked on these technologies now have agreed to work on WebAssembly. One way to describe it, it's a low-level language, an abstraction over what actual machine hardware can do in a way that is independent from the actual hardware. It can express programs, but these programs then can run on any machine potentially because it abstracts away the differences between the different machines. It's not something you would program indirectly, but that you would take another more high-level programming language and translate it into. The advantage of WebAssembly then is that you can take arbitrarily different programming languages and translate them into it, and have them run an arbitrary different hardware. So it's kind of like a mitigator between different languages and different hardware.

BEN TITZER

The problem in my mind is that there's a class of applications that make a lot of sense in their own domain which didn't work very well on the web. The web has essentially one blessed language and it has historically had just one blessed language, which is JavaScript. Other languages have compiled to that language because it's ubiquitous. However, it's not a very good compilation target. Because of that, languages like C++ where someone might have a native game they want to run on the web, and since they have all that legacy code, they want to compile it to run on the web. Now that WebAssembly will have threads, or be it maybe perhaps in a roundabout way that will give applications the ability to have a more background work, for example, so you could do a model view controller and actually have concurrent computation going on with your model view controller type of thing. I also think that because we have threads and concurrency that you can have heavier lifting being done so you can do even more computation, so even heavier 3D. I've heard the term "the HD web", I think WebAssembly is a key enabler for that in order to be able to do heavy computation and heavy graphics.

BRADLEY NELSON

Allowing the web to sort of do all the things is a really powerful thing. I think one of the issues with the web going back a long time has been that there are things you can and can't do well on the web, and WebAssembly goes a long way towards fixing that. You've got these a powerful multi-core machines, and while there were ways to try to take advantage of that partially, prior to WebAssembly and especially some of our efforts around threads and potentially around SIMD, a lot of the full capabilities of the machine were sort of off limits. Especially for high performance applications like games, that was a problem, but it also includes productivity applications. In general, the model sort of prescribed that you had to build the applications one way, it works the way of the web platform or not at all. I think for mobile, it'll open up sort of more opportunities for folks to get applications into platforms that have had their existence focused on app stores. The lack of capabilities especially in the mobile web have meant that for a lot of applications you have to do an app that's sort of the only option, and now you'll be able to say, "Well, maybe this works better as, as something that's on the web even for mobile." I think that it'll open opportunities for different kinds of programming paradigms. Folks that didn't fit into the style of how web applications have traditionally been developed will have more options, more programming languages. The opportunity for and the unfortunately challenging peril of mixing languages in more combinations, and the inter op and all of those issues.

ANDREAS ROSSBER

I have recently been giving talks with a title "neither web nor assembly" because I personally think it's kind of a misnomer because it was actually also from the get go designed to be not specific to the web. We have taken great care in designing it in a way that makes it work just as well in other environments than just the web, and the same qualities that make it interesting for the web also make it interesting in other contexts. For example, blockchain obviously is the one I should mention here first. Basically, any context where you want to run code in a way that is efficient and safe while being independent from specific hardware, so that you can write programs and distribute them to different hardware. That might be the web obviously, that might be blockchain computations, that might be mobile devices, that might be embedded devices, that might be content and delivery networks, things like that. One of its novelties is that it's completely mathematically specified with a computer verified specification. That also might be one quality that makes it interesting for blockchains because then you actually have a well-defined semantics you can reason about formally, maybe even with machine proof. You do smart contracts and there's lots of money behind them that you want to have some insurance on various levels that they do the right thing. In addition, since it's a portable format, it might also enable different platforms to communicate in a manner that they couldn't be doing so far because they all were using completely different formats of programs that didn't understand each other. It has this unifying fashion across different platforms and hardware that can potentially be useful for allowing programs to be distributed across different ecosystems even.

BEN TITZER

I see this as the ability to bring really powerful native applications to the web, so things that you might do really heavy work in, for example, AutoCAD or heavy audio or video processing, these types of applications to the web that maybe were not possible due to performance limitations, due to framework limitations. WebAssembly attempted to, and I think we did actually solve that problem to bring this type of application to the web.