 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
With more and more companies joining the WebAssembly (Wasm) ecosystem, Wasm is poised for meteoric growth.
And yet, in the hallway track at conferences and meetups, the skeptics of any universal runtime maintain a steady refrain. “It’s just Java Applets 2.0,” they intone. Taken at face value, their reluctance to drink the Wasm KoolAid is understandable. The scars of the omnipresent Java marketing mantra — “Write once, run everywhere” — are still there for any technologist of a certain age.
To refresh your memory, Java Applets are small applications written in Java and delivered to users as Java bytecode. These applets were executed within a Java virtual machine (JVM) separate from the web browser, providing interactive features to web applications that HTML alone could not offer. This was a very similar model to Wasm.
In their day, Applets were considered the path to a more powerful browser and many new computing paradigms. Yet, the technology failed to gain traction. It was deprecated from HTML standards and is rarely used today. Naysayers frequently point to the failure of Applets as a premonition of the fate of Wasm.
Yet, I will go out on a limb and say that this time, it really is different. Wasm will succeed where Java Applets failed to gain purchase in the global browser market for various reasons — community, performance, standards and general maturity of distributed computing.
Here’s why Wasm will succeed where Java Applets lagged: WebAssembly and Java Applets both have similar objectives and design goals — to allow web browsers to perform more compute-intensive tasks and to enhance the capabilities of browsers. The similarities stop there.
Both Applets and Wasm are sandboxed models intended to create an isolated runtime environment for compute that prevents security abuses. However, Wasm was designed with a zero trust mindset and a host-to-guest security model, which does not allow code to do anything outside of the runtime without explicit permissions.
More specifically, Wasm and Java Applets both aim to run code within web browsers, but their differences reflect the evolution of web security practices. Java Applets relied on a JVM sandbox and could request elevated privileges, leading to significant security vulnerabilities due to their complex runtime and broad API access.
In contrast, Wasm operates in a more restrictive sandbox without direct access to system resources. It minimizes attack surface through a linear memory model and enforces interface boundaries with the host environment. Unlike Applets, all permissions are granted before the module is executed, an inherently more secure approach. Wasm benefits from running natively in browsers and receiving frequent, automatic updates that enhance security.
Constant security updates to Java meant that updates were challenging, and browsers running Applets often had unpatched vulnerabilities. In other words, Wasm was designed as a web-first, web-native zero trust platform, whereas Java Applets were bolted onto a web environment more like an ungainly appendage.
As a WC3 standard, Wasm must be supported natively by every browser. This means users never need to install (or reinstall) Wasm. Security updates happen in the background without bothering users. With Applets, updates to the JVM caused constant headaches, and, in general, the browser integration was less well-designed and executed. Equally critical, Wasm was designed to be screaming fast out of the gate. Applets were performance hogs that launched slowly and refreshed badly.
Wasm is fast enough to power “real-time” use cases such as autonomous vehicles, interactive multiplayer games or artificial intelligence — all use cases Java Applets could never touch. Another sign of Wasm’s bright future is the rapid growth of use cases on the server side; Wasm’s fast load time and performance mean critical backend applications can hit even stringent performance targets. (Note: This is why we are building Wasm as a core component of our open source Unit application server stack).
Wasm was formed as a collaborative effort to make browsers more useful and powerful. Created by a community, it was open from the start and never owned or controlled by any one organization. Java (and Applets) was built by Sun Microsystems and inherited by Oracle, which maintains fairly tight control of the community.
The openness and broad supporting community bodes well for the future of Wasm; the most successful open source projects like Linux and Kubernetes and standards are controlled by neutral communities. The Bytecode Alliance, likewise, is a neutral community governed by a diverse array of interests. This both enhances the legitimacy of Wasm and also builds the confidence of companies looking to adopt the technology for critical applications and use cases.
WASI 0.2.0 and other improvements to Wasm clear another hurdle for rapid adoption and growth. Yes, there remains work to be done. One area where Java Applets had a short-term advantage is in tooling.
The controlling company could build and vertically integrate much of that, simplifying developer toolchains for building Applet-dependent applications. But over time, this advantage wanes and reverses. A broad community will create a wider array of tools and foster a broader array of talent to propel ecosystem growth. Wasm already supports more languages in the runtime than Applets ever did, providing a core foundation for a better developer experience.
Both Java Applets and Wasm had a grand vision for the future of the Web. In all fairness, Applets probably got there before the future was evenly distributed, and maybe the story might have been different had Java been ascendant in tandem with the cloud, serverless, containers and all of the other new modalities of modern, distributed applications and computing.
That said, the fundamental differences between Applets and Wasm are deeper than mere timing. Rather than just being one use case among many like Applets was to Java, Wasm was purpose-built to be the runtime of the Web, with a zero trust security model and high-performance profile, designed by the community rather than by one controlling entity. The difference is deep in the DNA, and that’s why Wasm will win where Applets labored.
