The rise of WebAssembly

In just four short years, WebAssembly has broken free of its origins as a useful browser-based technology and now powers some of the world’s most complex distributed applications, from streaming platforms like Disney+ to e-commerce powerhouse Shopify.

WebAssembly’s journey beyond the browser

WebAssembly, or WASM for short, was developed by the World Wide Web Consortium (W3C) and first published in 2018. It is, in their words, a “compilation target,” which means developers can bring their own code—typically Rust, C++, or AssemblyScript—and WebAssembly compiles it to bytecode to execute on the web browser at high speed.

Then, in 2019, Mozilla introduced its WebAssembly System Interface (WASI) to access operating system resources and break WebAssembly out of the browser to help run back-end applications in a similar way.

As a result, “developers are starting to push WebAssembly beyond the browser, because it provides a fast, scalable, secure way to run the same code across all machines,” wrote Fastly senior principal engineer Lin Clark in a 2019 blog post.

This shift in WebAssembly’s reach even drove the Docker cofounder Solomon Hykes to tweet in 2019 that, “if WASM+WASI existed in 2008, we wouldn’t have needed to create Docker. That’s how important it is. WebAssembly on the server is the future of computing. A standardized system interface was the missing link. Let’s hope WASI is up to the task!”

That’s high praise, and indeed, for its biggest exponents—like Kevin Hoffman, the creator of CNCF sandbox project WasmCloud—WebAssembly is on the precipice of being as industry-changing as Docker was back in 2013.

“One of the things we want in our cloud solutions is things to be small, fast, secure, and portable,” Hoffman told InfoWorld. “When WebAssembly turned up to provide this … that set off all sorts of alarm bells for me to build things on the back end and out at the edge.”

This expansion of WebAssembly has seen interest in the technology rise by 43% on Stack Overflow since the start of 2021.

What WebAssembly must address to meet enterprise needs

Still, there are some significant steps that need to happen for WebAssembly to achieve its potential on the enterprise stage, said Gartner analyst Fintan Ryan. “I think it is a truly revolutionary technology, but the trajectory is still quite slow,” he told InfoWorld.

Today, WebAssembly remains a fairly complex, low-level technology that is mostly popular with specialist providers running large-scale content streaming platforms, high-intensity content distribution networks (CDNs)—such as Cloudflare Workers—as well as with large platforms where developers can run intensive workloads isolated from one another, as e-commerce platform Shopify has done.

Sluggishness in pushing the WebAssembly standards forward from the W3C and a lack of truly compelling, developer-friendly packaging tools are two major factors hampering mainstream adoption of WebAssembly.

“We are all anxiously waiting to see what happens with the WebAssembly standard and see WASI evolve to meet all of our secure network demands to start writing powerful network-enabled workloads in pure WebAssembly, and not have to rely on proprietary runtimes to do that,” WasmCloud’s Hoffman said.

WebAssembly pushes the envelope in the enterprise

While the rest of the industry waits for that Docker moment, here are three examples of companies already pushing WebAssembly to its limits.

Bloomberg: Defining the future of Terminal with WebAssembly

Performance is obviously paramount for clients of financial data specialist Bloomberg, as the world’s leading financial institutions expect up-to-date data and the ability to bend that data to their unique requirements.

The hugely popular Bloomberg Terminal application displays financial data on a user’s multiple screens using a proprietary tabular data processing engine written in C++, which is wrapped with an embedded Chromium browser front end hosting thousands of JavaScript applications.

“Potentially increasing the execution speed of some computations is where WebAssembly opens up opportunities for us to improve the performance of our web-based components,” Itay Dafna, a software engineer at Bloomberg specializing in quantitative analytics, told InfoWorld.

One service that Dafna’s team maintains is BQuant, a Python application built on Jupyter notebooks that integrates with Terminal to allow analysts to build, test, and share their own research of Bloomberg data. Dafna and his team started to see the potential for WebAssembly to let users share their results outside of Bloomberg platforms as an independent, embeddable web component.

“A typical architecture of such components separates the front end, where artifacts are rendered, from the back end, where computations happen. In our case, the component needed to run in a hybrid mode—both in a Jupyter notebook with a Python kernel, as well as stand-alone in the browser,” Dafna said.

“If we write data modeling and computation logic in WebAssembly, we can run it in the Python kernel and also in other environments, such as the web, with identical results,” he said, emphasizing that being able to run both a Python and JavaScript version of the application with “identical results” was previously unthought of.

However, Dafna admits that bringing this into production “was not easy,” mainly because Python code running in WebAssembly doesn’t currently come with a standardized virtual machine (VM) format. Although WebAssembly works seamlessly in the browser today, for anything written in Python, “you have to roll your own, and that required a lot of heavy lifting and scaffolding code to be written by us.” This limits the “write once, run anywhere” promise of WebAssembly.

That being said, Dafna and the broader engineering community at Bloomberg remain committed to WebAssembly. “We are very excited at Bloomberg about this technology and see it as an important part of the future of the Terminal ecosystem,” he said. “We are still looking for more places to integrate it where it makes sense and, once more features get added to the WebAssembly language standards and more tooling becomes available for developers, that will make it much easier to adopt.”

The BBC: Moving into the metaverse with WebAssembly

If we are moving toward a world where home entertainment is no longer just streaming video and audio but also rich interactive experiences and even virtual or mixed reality experiences within the metaverse, how can that be supported on the devices found in the average person’s home today?

These are the sort of questions being asked inside the research and development department of the BBC as it looks to sketch out the next iteration of its hugely popular iPlayer video streaming application, one that “can deliver immersive, interactive experiences,” Tim Pearce, an R&D engineer at the BBC, told InfoWorld.

While the current iPlayer has multiple client application code bases for various target platforms—iOS, Android, smart TVs, responsive web, and legacy devices—WebAssembly has the potential to become a common translation layer for all these platforms and more in the future.

“We think that WebAssembly provides the perfect solution to the challenges we face,” Pearce said during a session at the 2021 WebAssembly Summit. “WebAssembly allows internal and external developers to author individual experiences in the language and tools of their choice, such as a games engine, to produce a universal binary that is both performant and sandboxed from other experiences on the platform.”

This could become crucial in a future where the BBC commissions rich interactive experiences in the same way as it does broadcast content today. “What WebAssembly does there is allow us to download application code and trust that it will not interfere with other applications on the platform,” Pearce said.

This idea eventually became a prototype platform, called the Single Service Player (SSP), built by the BBC’s R&D department. It aims to enable the running of multimedia applications across a wide variety of target platforms from a single C++ code base in a secure, sandboxed manner.

Adopting WebAssembly at the BBC hasn’t been a panacea, though. Asking engineers to switch from JavaScript to C++ or even to Rust is going to be “a big challenge” for Pearce and his team, and there are still some major gaps that need to be filled by engineers to get WebAssembly to live up to its promise.

For example, when building the SSP, BBC R&D engineers soon found that the glue code required so the Wasmtime runtime could give the WebAssembly module access to various multimedia functions didn’t yet exist. So they built an import function by hand. The effort was worthwhile, though: the SSP can now consistently target both web and native platforms using WebAssembly.

“WebAssembly is great outside of the browser for the same reasons it is great inside the browser: performance, namely, and running in a safe, sandboxed way,” Pearce said. “But that has to sit on top of a runtime, and the initial phase of that has been WASI and the community group setting that standard. At the moment that hasn’t moved on quickly.”

Amazon and Disney: WASM delivers for the streaming platforms

Having hit 130 million subscribers at the end of 2021, the fast growth of Disney’s streaming service Disney+ since its launch in November 2019 has seen demand balloon for native applications across mobile devices, set-top boxes, smart TVs, and game consoles.

“To meet this growing demand for our service to be installed locally on set-top boxes, Disney streaming needed to develop unique software that would enable a baseline for our partners to deploy with, that gave them access to our content fast and efficiently, while still enabling us to control the environment and ensure a quality of experience that our customers expect,” wrote Mike Hanley, vice president of software engineering for Disney streaming, in a September 2021 blog post.

Disney engineers started building this portable runtime in 2019, starting in C and with the client application in Rust, targeting WebAssembly and remotely hosted on AWS. This eventually evolved into the Disney+ application developer kit (ADK), which provides external developers with “a clean abstraction layer” and “well documented program for our distributors, who know their hardware and software best, to port our runtime to their devices.”

Talking about the whole ADK stack, and not just WebAssembly, Hanley and his team concluded that “only with this technology are we able to meet the market demand at scale and control our experience while ensuring that our customers are satisfied with a consistent experience every time they see the Disney+ logo, no matter what device they are on or where they choose to experience our content.”

Similarly, engineers working on Amazon’s Prime Video streaming service turned to WebAssembly as the means to better update its application across a growing range of devices and platforms.

“At Prime Video, we’re delivering content to millions of customers on more than 8,000 device types, such as gaming consoles, TVs, set-top boxes, and USB-powered streaming sticks. When we want to do an update, every one of those devices requires a separate native release, posing a difficult trade-off between updatability and performance,” wrote Alexandru Ene, a principal software engineer at Amazon Prime Video, in a company blog post.

In August 2020, Ene and his team started investigating how WebAssembly might execute tasks that were being performed by JavaScript components. “In those experiments, code written in Rust and compiled to WASM was 10 to 25 times as fast as JavaScript,” he wrote.

“We can’t just rewrite the Prime Video application in Rust and run it on a WASM VM, however, as it still needs to run on legacy devices and browsers that don’t have WASM support,” Ene wrote. Instead, the team decided to only move select low-level systems from JavaScript to WASM, a change that has seen average frame rates on mid-range TVs go from 28ms to 18ms, and from 40ms to 25ms on less-capable devices. “To reach our goal of reliable 60-frame-per-second frame generation and improve input latency, we will move more systems to WASM,” Ene noted.

What next for WebAssembly

One thing that is undeniable from these three examples is the sheer amount of heavy lifting still required by engineers to make WebAssembly a truly viable enterprise solution. If the technology is to ever bring its performant, portable, and secure code to the mainstream, that needs to change.

“Right now, it is for folks that can deal with the tool chains or have the sort of teams to set them up for them,” Gartner’s Ryan said, “but it should be for everyone.”

“The tools have grown up a lot, but there is still a lot of work to go over the next year to improve on that tooling story for the regular developer experience and being able to compile to WASM and run it outside of the browser,” said Luke Wagner, a former Mozilla developer who now works at Fastly and is co-chair of the WebAssembly working group.

WasmCloud’s Hoffman said, “The thing that I think will push WebAssembly over the edge as the de facto standard for distributed applications is when all major language compilers can target and convert basic networking code to something that is WebAssembly compatible, so that it just works.”

For all of its progress so far, some industry watchers, like Gartner’s Ryan, don’t see WebAssembly ever matching the sort of explosive growth that Docker did. Not necessarily because the technology is less useful, but because “there isn’t a brand behind it organizing meetups and doing all of the work that drove that awareness. The other part is people are still figuring out the use cases, which are less clear than with containers.”