Java’s History Could Point the Way for WebAssembly

It’s hard to believe that it’s been over 20 years since the great dotcom crash happened in 2001, which continues to serve as a harbinger of potential doom whenever cyclic tech is on a downward path. I remember quite distinctly hanging out with either unemployed or underemployed folks in the IT field shortly after the great crash in 2001. We were doing just that: hanging out with time on our hands.

During that time, one day in a park in New York City, Brookdale Park in Montclair, NJ, one of my friends was sitting on a park bench pounding away on his laptop, and he said there was this really cool thing for website creation called Java. It’s been around for a long time, actually, but described how amazing it was that you could program in Java code and deploy, where you want on websites, he said. And of course, have played a key role in transforming the user experience on websites compared to the days of the 1990s when HTML code provided the main elements of website design. Sure, why not, I’ll check it out, I said. And the rest is history as Java secured its place in history, not only for web development, but across IT infrastructure.

Flash forward to today: There’s this thing called WebAssembly or Wasm, which is offering a very similar claim. of where you write once and deploy anywhere. Not only for web applications for which it was originally created, but across networks and on anything that runs on a CPU.

Remind you of something?

“Wasm could be Java’s grandchild that follows the same broad principle of allowing developers to run the same code on any device, but at the same time Wasm fixes the fundamental issues that prevented the original vision of “Java on any device” from becoming reality,” Torsten Volk, an analyst for Enterprise Management Associates (EMA), told The New Stack.

The Simple Case

Wasm has shown to be very effective in a number of different hardware environments, ranging from server-side to edge deployments and IoT devices or wherever code can be run directly on a CPU. The code runs bundled in the neatly packaged Wasm executable that can be compared to a container or even a mini operating system that can run with significantly less — if any — configuration required for the code and the target. Wherever code can be deployed, essentially, the applications are much farther out than just being confined inside the web browser environment. The developers thus creates the code and deploys it. It can really be that simple, especially when PaaS solutions are used.

Most importantly, Wasm enables true “code once, deploy” anywhere capabilities, where the same code runs on any supported device without the need to recompile, Volk noted. “Wasm is not tied to one development language but supports Python and many other popular languages. Developers can run their code on shared environments on servers and other devices without having to worry about the underlying Kubernetes cluster or hypervisor,” Volk said. “They also receive unified logging and tracing for their microservices, right out of the box. This simplified developer experience is another big plus compared to Java.”

During a recent KubeCon + CloudNativeCon conference, a talk was given about using Wasm to replace Kafka for lower latency data streaming. At the same time, Java continues to be used for networking apps even though alternatives can offer better performance, but developers kept using it because they just liked working with Java. So, if Wasm’s runtime performance were not great — which it is — developers might still adopt it merely for its simplicity of use.

“One of the big pluses of Wasm is that it is very easy for developers to get started, just by deploying some code and instantly watching it run. This is one of these value propositions where it may take a little while to fully understand it, but once you get hooked, you don’t want to worry about the ins and outs of the underlying infrastructure anymore,” Volk said. “You can then decide if it makes sense to replace Kafka or if you just want to connect it to your Wasm app.”

Java’s entire “write once, run anywhere” promise is quite similar to WebAssembly‘s, Fermyon Technologies CEO and co-founder Matt Butcher told the New Stack: “In fact, Luke [Luke Wagner was the original author of WebAssembly], once told me once that he considered Java to be 20 years of useful research that formed the basis of how to write the next generation (e.g. Wasm),” Butcher said.

Still Not the Same

There is one key difference between Java and Wasm: their security postures.

Its portability and consistency can make security and compliance much easier to manage (again, it runs in a binary format on a CPU level). Also, part of Wasm’s simplicity in structure means that code is released in a closed Sandbox environment, almost directly to the endpoint. Java’s (as well as .NET’s) default security posture is “to trust the code it is running,” while Java grants the code access to the file system, to the environment, to processes, and to the network, Butcher said.

“In contrast, Wasm’s default security posture is to not trust the code that is running in the language runtime. For Fermyon (being cloud- and edge-focused), this was the critical feature that made Wasm a good candidate for a cloud service,” Butcher said. “Because it is the same security posture that containers and virtual machines take. And it’s what makes it possible for us as cloud vendors to sell a service to a user without having to vet or approve the user’s code.”

In other words, there are just an exponentially greater number of attack points to worry about when working with distributed containerized and microservices environments. Volk agreed with Matt’s assessment, as relying on the zero trust principle allows for multitenancy based on the same technologies, like mTLS and jwt, that are already being used for application containers running on Kubernetes, Volk said. “This makes Wasm easy to safely try out in shared environments, which should lower the initial barriers to get started,” Volk said.

Another big difference between Java and Wasm — which can actually run in a Linux kernel — is that Java requires JVM and does not require additional resources, such as a garbage collector, Sehyo Chang, CTO at InfinyOn, told The New Stack. “Wasm, on the other hand, is very close to the underlying CPU and doesn’t need GC or other heavy glue logic,” Chang said. “This allows Wasm to run on a very low-power CPU suitable for running in embedded devices or IoT sensors to run everywhere.”