WebAssembly in the Browser Matures and Cool Things Happen
WebAssembly is experiencing an acceleration of its usage and applications for the browser. However, this doesn’t imply that server deployments and the so-called component model, won’t achieve their full potential for Wasm.
Indeed, several promising developments are emerging, both for the component model, with the establishment of the WASI 2 preview, and in the server space, with intriguing offerings from Fermyon for serverless development applications that WebAssembly underpins.
Once finalized, a component model that will enable WebAssembly to not just see its expanding use beyond web browsers and servers — but will be able to allow users to deploy different applications running inside numerous lightweight modules at very high speeds across thousands of endpoints simultaneously through a component interface without changing one iota of code.
Meanwhile, a noticeable snowball effect is occurring in WebAssembly for the browser space. Many of these developments, while anecdotal, are quite interesting.
In this article, we explore some of the interesting projects we’ve encountered for WebAssembly in the browser and describe them. Then we delve into what needs to happen for WebAssembly to reach its full potential. Much of it has to do with the open source community.
CheerpJ 3.0
Recently launched, CheerpJ 3.0 showcases an interesting manifestation of WebAssembly for the browser, demonstrating its potential to deploy and operate complex applications and runtimes written in Java. Developers can create applications in any language and deploy them with just a click, packaged and distributed for availability in testing and usage by end-users.
While CheerpJ 3.0’s development remains ongoing, of course, it represents a significant advancement in deploying applications in the browser with WebAssembly, particularly with Java. This complements other projects focused on encryption and the ability to deploy applications written in C++ for browser usage.
With CheerpJ 3.0 — marking its generally available release — Java client applications, such as Java Applets, Java Web Start applications, and stand-alone Java Applications, can run unmodified on modern browsers, without a local Java installation, Fermyon says. The idea is to make runtimes — in this case Java — better able to run as if the user had the resources of the endpoint server at their disposition — in the browser.
“In the same way that Docker allows you to run containers of binaries on your machine, you need to be able to have technology and it has technology that allows you to do the same to run binary workloads in the browser in the same way that you can do normally on a normal platform operating system,” Stefano Marco Maria De Rossi, CEO and founder of Leaning Technologies, which created CheerpJ, told The New Stack.
Setting up CheerpJ 3.0 is reasonably straightforward, with clearly outlined steps in the documentation, and it is compatible with essentially any browser. In the playground aspect, merging PDF files is remarkably simple: users input their PDF files into the API, and with a few clicks, the files are merged.
However, this simplicity is akin to a Hello World application, representing just the beginning. For more complex applications, Java can be written and implemented into the WebAssembly module of CheerpJ 3.0 for distribution and execution across browsers. These examples illustrate the versatility and potential of WebAssembly for browser-based applications.
Falco’s Browser Run
Jason Dellaluce, a senior open source engineer for container security provider Sysdig and a Falco core maintainer, said during his talk at KubeCon + CloudNativeCon North America. In his talk “The Falco Playground: A Cocktail of WebAssembly and Runtime Security” he explained how the security platform that heavily integrates eBPF needed to “fill a historical gap.” The gap originated from how Falco is responsible for both validating rule sets and providing indications “in case something is wrong,” and then configuring those rule sets to be matched against security events at runtime, testing that “everything works as expected,” Dellaluce said.
He figured Falco would require a backend server to run Falco and then a web platform for our users to use in order to experiment with Falco in a sandbox environment. “That is a solution, but it’s also costly to develop, maintain, and deploy because we need servers in our open infrastructure… And then it hit me: WebAssembly lets you compile programs in most languages into something that runs natively in your browser client-side.”
The Falco Playground was then created for his project for Google Summer of Code. “It’s the new platform that we just bootstrapped to let people play and learn about Falco rules and testing then,” Dellaluce said. “This is all client-side without the need for any backend, thanks to the power of WebAssembly.”
And it runs in the browser.
During the KubeCon + CloudNativeCon talk “Running Linux-Based Containers on Wasm and Browser with Container2wasm Converter,” Kohei Tokunaga, a software engineer at Japan NTT who is a maintainer of BuildKit and a reviewer of CNCF Containerd, described how Container2wasm Converter can be used to run Linux-based applications on Wasm and the browser without modifications to the application apps. As he described, porting apps to Wasm costs time for recompilation and re-implementation.
Container2wasm Converter allows for modified containers on Wasm to be run while leveraging the CPU emulators. His team has also created an extension for VS Code for the browser in order to run containers on the browser. He described additional project plans to develop performance analysis and other improvements to Container2wasm.
Adobe Touch
Again, Wasm continues to see use in its capability to take advantage of its targeted binary structure in a number of ways. These include how it functions on a CPU level and removes many of the risks associated with vulnerable code in container images, among other touted advantages. In Adobe’s case, the resource-intensive application Photoshop when running on a PC is now available on the browser. The user accesses the commands and functionality of Photoshop without having to download the software (again, thanks to Wasm).
Photoshop’s availability to run on the browser is largely due to Adobe’s use of open source emscripten. Emscripten is a compiler toolchain for Wasm modules for C or C++. This means that you can use emscripten to compile code written in C or C++ or other languages that use LLVM into WebAssembly that can be run not only on the browser but in Node.js or other WebAssembly runtimes.
Browser Wasm Future
For the future, developers, especially, require more maturity and stability, De Rossi said. Particularly in the last two years, the biggest investment in Java has been about usability and developer experience, De Rossi said. “Really, one of the biggest motivations has been to completely re-architecture. Okay, that was so it’s trivial to use for the standard Java developer, which was our motivation,” De Rossi said. “So I think this is very important if you want these tools for this problem to actually succeed on a large scale.”
Normal software uses a lot of third-party dependencies, of which the user or developer does not have the source code, while many enterprise software developers will use proprietary libraries, De Rossi said. “How do you enable the browser for wiser use in these types of applications, which comprise 99% of them? Proprietary components — how do you deal with that? How do you solve that?,” De Rossi said. “The solution is virtualization — being able to run binary content on the browser, being able to run x86 or Arm binary content. That’s what you need to be able to do because otherwise, you will never be able to run software that has proprietary components and you will always be limited to either your own source or open source components.”
