Forrester on WebAssembly for Developers: Frontend to Backend
There are a lot of things to love about WebAssembly — but how do developers decide when to use it? Does it matter in what language you write to WebAssembly? And what about security? To learn more about what frontend developers need to know, I sat down with Andrew Cornwall, a senior analyst with Forrester who specializes in the application development space.
The good news is, functionality does not alter depending on which coding language you write in. Write in C++, AssemblyScript, Rust — it’s the developer’s choice, Cornwall said. Typically, it’s easier to compile languages that do not have garbage collectors, so languages such as Java, Python, and interpreted languages tend to be more difficult to have running in WebAssembly than languages such as C or Rust. But the end result will be WebAssembly, which he noted is best thought of as a processor rather than a language.
“Something like JavaScript or Java or Python, where there’s a whole ecosystem in there that needs to be in place before you can run,” Cornwall said.
Typically, developers will take the C implementation of Python, compile it using a compiler that outputs WebAssembly, he said. Now they have a Python interpreter that is written in WebAssembly, which they can then feed regular Python code.
“That is easier to do than converting Python to WebAssembly itself,” he added.”Once it’s in WebAssembly, it doesn’t matter. It just runs — it’s essentially very similar to machine code.”
For other supported languages, rather than compile to x86 or Arm on a compiler, developers opt for WebAssembly when compiling, he explained. The compiler outputs the byte code that will run — WebAssembly, or Wasm, is a low-level byte code that can be translated to assembly. A bytecode is computer object code that an interpreter converts into binary machine code so it can be read by a computer’s hardware processor. Essentially, WebAssembly converts code to this portable binary-code format. As such, it has more in common with machine language than anything else and that’s why it’s so gosh darn fast.
Wasm Use Cases for the Frontend
When WebAssembly first came out, it was seen primarily as a solution for frontend needs, Cornwall said. Typical use cases for the frontend include operations with a lot of matrix math and video. If you need something to start executing right away and don’t have time to wait for the JavaScript to download and parse in the browser, then WebAssembly is a great solution, he said. For instance, the BBC created a video player for its site in Wasm and Figma is written in C++ and compiled to WebAssembly, where it cut load time by three times.
“WebAssembly can be streaming so you can download it and start executing it right away,” Cornwall said. “Other than that, the other interesting use case for WebAssembly on web front ends is going to be not so much for JavaScript developers, but for developers of other things.”
That’s in part because JavaScript running through the just-in-time [JIT] compiler is actually pretty fast, he said, adding that developers can get to half native speed with JavaScript “if you let it run long enough.” For other developers, Wasm means they can write in their favorite, supported code and then compile to Wasm for the frontend.
“The interesting parts where WebAssembly gets used are essentially things where you’d go down to machine code if you were writing a program in another language,” he said. “If there is something that needs to be really fast right away, and you can’t afford to wait for the JIT to bring it into high speed by optimizing it, or if there is something you need it to start right away and you don’t want to wait for the time for the JavaScript to be parsed, for instance, so you have it in WebAssembly.”
Wasm for the Backend
Then a funny thing happened along the way to the assembly (ahem): Wasm started to become less of a frontend thing and more of a backend thing as it began to be leveraged for serverless compute, he said.
“WebAssembly VMs [virtual machines] start really fast compared to JavaScript VMs or containers,” he said. “A JavaScript VM starts in milliseconds, so 50, 100 milliseconds; WebAssembly VMs can start in microseconds. … If you’re running serverless functions, that’s great because you make a call out to the server and say, give me the result. It can then start up and give you the results really quickly, whereas other things like Javascript VM, Java VMs and containers have that startup time the cost that it takes to for them to start running before they can then do something with the values that you’re passing them and give you the result.”
That includes Kubernetes containers, he added. And there are places — serverless functions or where the web browser wants to make a request of a search function — where developers would want to use WebAssembly VMs instead of a Kubernetes container, he added.
“If you send that search request off, you’re waiting until the container comes up, runs the code the search code itself and then sends the result back. Often containers will allow multiple connections because it’s expensive to bring a container up,” he said. “So Kubernetes, it has a cost to bring the container up. With WebAssembly you don’t have as much of a cost. It’s microseconds to come up rather than milliseconds; or even if it’s a container, it could even be hundreds of milliseconds or getting close to half a second.”
Multiple that by 1000s and those milliseconds start to add up.
How Wasm Improves Security
There’s also a security risk in containers because people tend to reuse them rather than shut them down and start over. That’s not an issue with Wasm.
“Then you need to worry about how did what someone that came before me affect what the current person is requesting or what the current request is going on?” Cornwall said. “With WebAssembly it’s so cheap, you just throw it away. You can just write a serverless function, start up the VM, execute the serverless function and then throw it all the way and wait for the next request.”
Not that Wasm is a replacement for containers all the time, he cautioned. Containers are still needed and make sense when running big queries on large databases, where adding another 300 milliseconds to the query really doesn’t make much of a difference.
“Things like that will probably stay in containers because it is a little bit easier to manage a container, at least right now, than it is to manage WebAssembly serverless functions that just kind of float around in space,” he said. “WebAssembly is going to be an addition to when you need to make fast calls to serverless functions, as opposed to taking over for all containers.”
Another way Wasm is more secure than other options is that it will only execute within its sandbox — nothing goes outside of the sandbox. That’s why so far the biggest security threat seen with WebAssembly has been from websites where bitcoin miners were hidden in the Web Assembly, causing the website user to unwittingly loan CPUs for bitcoin mining. It’s not possible for code compiled into Wasm to reach and send out passwords, for instance, because the code stays within the Wasm sandbox, Cornwall explained.
