Wasm for the Frontend: A Look at Developer Use Cases

When Second State started in 2019, the major use case for WebAssembly was in the blockchain, to run smart contracts.

“You really need a lightweight environment, a sandbox to run them [blockchains], and Docker — or containers in general — was too heavy for that, because in the span of six seconds, you have to do 1,000 of those,” said Michael Yuan, CEO of Second State.

The Austin-based startup instead focuses on offering support for WasmEdge, a WebAssembly runtime for cloud native, edge and decentralized applications. WasmEdge is open source and an official sandbox project hosted by the Cloud Native Computing Foundation (CNCF), an open source, vendor-neutral hub. WasmEdge is derived from the same standard as WasmTime, a Bytecode Alliance project.  Essentially, they’re the same, Yuan told The New Stack.

“However, I think our distinct offerings or features are the development toolings and APIs around that,” Yeon said. “For instance, we are embedded into Docker desktop so every Docker user gets a copy of WasmEdge instance.”

Applications can be written in either Rust or JavaScript and run inside the Wasm container instead of a more traditional Linux container, he added. Kubernetes can manage both types of containers.

Wasm for the Frontend

However, when it comes to using Wasm on the frontend, it’s most often used to support serverless functions, Yuan explained. TikTok, for instance, has deployed Wasm for serverless. In that use case, Wasm is running in the browser. Another more widely deployed use case is providing the frontend with dynamic content from the backend, he said.

“The backend could have services, or nowadays, it’s more common to use serverless functions or microservices,” he told The New Stack.

The relationship between Wasm and JavaScript is complex, Yuan added. When Wasm was first started in the browser, it was widely perceived as a supplement to JavaScript, he said. JavaScript was too slow for some functions, and its alternative, C++ applications in the browser, was too unsafe.

“That’s where WebAssembly comes from,” he said. “There’s a bunch of companies that do that, like Figma does that. And you have WebAssembly runtimes in all major browsers, but those are all WebAssembly runtimes written by, say, Google and Apple. So that’s one side of the things — Wasm runs side-by-side with JavaScript.”

Wasm might be used when a program needs to do computational work, JavaScript’s processing time is too slow, or the developer wants to use a C++ library. The library can be passed off to the WebAssembly runtime that sits in the browser. Prior to 2019, that was the most common use case and it’s still widely used today.

The BFF — Backend for the Frontend

Another reason frontend developers should know about WasmEdge and other Wasm runtimes is that frontend developers are doing more backend work, he said. There’s a lot of BFF — backend for the frontend.

“Frontend developers used to only care about frontend, but since the emergence of Vercel, Netlify and companies like that, I think they are doing more of what’s traditionally known as backend work,” he said. “Now, they call them serverless functions or edge functions, meaning a service function does a variety of different things. It can do database stuff, although it’s less common, but in the context of Vercel, it does a lot of server-side rendering, so instead of having rack components rendered in the browser, we render them on the server. What we call cloud native WebAssembly runtimes, are running outside the browser.”

Rust is probably the most common language for compiling to Wasm, he added. Typescript also compiles to Wasm.

“One of the unique features of WasmEdge is that we have ported the JavaScript runtime and its entire Node.js stack into WasmEdge. So you can run Node.js on the server inside WasmEdge and on the frontend, you have a regular React.js application,” Yuan said.

Running all of the JS in a Linux container would be in the hundreds of megabytes, he said. By comparison, running Node.js inside the Wasm container or inside WasmEdge is a mere 510 megabytes. This difference in size can be particularly important in AI inference, which is using a model to make a prediction about, say, facial recognition.

“It’s a ten times space-saving, and in performance,” he said. “So that’s the primary reason why the JavaScript people are more interested in this.”

Another use case of backend supporting frontend is deploying Wasm inside databases or data processing pipelines, connected with Kafka messaging queues, he said.

“To me, this is really a big trend that’s happened in perhaps the past five years: Is the frontend developer moving to the backend?” Yuan said. “A lot of companies and a lot of tools are built around that idea.”