Interview WebAssembly will not magically speed up your web application and may be as significant running in environments other than web browsers as it is within them, a co-designer of the language told The Register.
WebAssembly (Wasm) was formally approved as a W3C recommendation in December 2019. The technology is a low-level programming language designed to be compiled into machine code for execution with the performance of native code. A Wasm virtual machine is embedded into a host such as a web browser, where code runs in a sandboxed environment and respects the browser's security policies. It is implemented in Google Chrome, Mozilla Firefox, Apple Safari, and Microsoft Edge (both the original and Chromium-based versions).
There are languages that compile to Wasm, including C/C++, Rust, and others in various stages of experimental support, including Go, C#, TypeScript, Java, Ruby and Swift.
There is also a misconception about what is actually slow on the web. For most typical web pages that are not computation-heavy, it's not the execution of user code that is the most expensive. It's all the rendering and the dynamics of that going on, and that is not affected by WebAssembly.
Wasm has lots of promise for improving the performance of web applications, but its reputation was tarnished when researchers at the Technische Universität Braunschweig in Germany looked into its usage on the million top websites as listed by Amazon's Alexa analytics. According to their June 2019 paper (PDF), one in 600 of these sites execute Wasm code, but in 55.7 per cent of these cases, it was being used for cryptocurrency mining, a form of parasitic computing whereby users are tricked into generating revenue for a third party.
Faster web apps, or stealthier malware?
Is Wasm speeding up the web, or opening up new forms of malicious computing? We spoke to Andreas Rossberg, a senior staff researcher and engineer at Dfinity and a member of the W3C WebAssembly Working Group. Formerly at Google, he was co-designer and specification author of WebAssembly.
"There is also a misconception about what is actually slow on the web. For most typical web pages that are not computation-heavy, it's not the execution of user code that is the most expensive. It's all the rendering and the dynamics of that going on, and that is not affected by WebAssembly."
What this means is that an ideal use case for Wasm is for libraries that are computationally intensive, in areas like multimedia editing, simulation, compilers and debuggers, encryption, and games. Most developers should not have to think about Wasm. "For the average developer, they will have to rely on libraries providing this. And that's intended," said Rossberg.
WebAssembly future: three big themes
There are three areas which Rossberg identifies as significant future developments. One is better support for high-level languages, as mentioned above. Another is a "new initiative called WASI, WebAssembly System Interfaces, which is an infrastructure for defining and providing modules for the WebAssembly ecosystem, that could be used across different environments.
"When you are running an application on the web, the environment is quite different from traditional operating systems, there are things you don't have and can't do. If you want to port software, you need to emulate quite a bit of stuff. It seems useful to have a generic infrastructure in which can define something like a virtual operating system on top of WebAssembly. It's still pretty early.
"The third thing is that WebAssembly is gaining traction outside the web. My company is doing just that, using WebAssembly in distributed computation. There is the edge computing use case, as a means for sandboxing execution. There are people who want to put it into IoT and embedded devices. I predict that we're going to see a lot more adoption and real-world use in all these other spaces."
Is this just reinventing Java's JVM? Cross-platform is a big benefit, and so is sandboxing, but it is not new.
"When we designed WebAssembly, we carefully looked at existing things like the JVM and .NET, and tried to learn from the problems they had. One of the big differences, design wise, is that WebAssembly is more low-level. It's just a virtual instruction set that mirrors what common CPUs provide. It's not an abstraction over a specific programming language like the JVM or .NET. The JVM Is almost just abstract syntax for Java. It's not necessarily a natural fit for other languages that compile to it, even if you can do that. And it's pretty heavyweight; there's Java's object model in there.
"This is exactly the opposite of what we try to do with WebAssembly. We do something that is agnostic of whatever is your source language, and that also makes it more lightweight. That makes it more attractive to constrained spaces like embedded."
Another difference is in the sandboxing. "We were very careful with WebAssembly to have a machine-verified proof of its safety," said Rossberg. This means avoiding things like Java's JNI (Java Native Interface) or .NET's Platform Invoke. "The concept in WebAssembly is that you can import stuff from your host environment, that is hosting the WebAssembly engine. For example, a web browser would define a certain interface that WebAssembly can see in order to provide certain functionality. That interface would have to be provided by the host."
WebAssembly has lots of promise, despite common misconceptions, but the name, said Rossberg, is itself confusing. "I used to give talks which were titled, neither Web nor Assembly." On one thing he is clear though. "The shorthand is officially spelled Wasm, not WASM - it's a contraction, not an acronym." So there is no need to shout. ®