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.
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
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.
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.