 |
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.
WebAssembly, or Wasm for short, has long promised to revolutionize application development. The dream was simple yet powerful (and familiar): Write your code once and run it anywhere. Wasm also promised to run code at near-native speeds. Even better, unlike previous attempts at universal runtimes like Java applets, Wasm offered stronger security guarantees and a rock-solid default security posture with a deny-by-default nature — access to system resources is disabled unless a developer indicates otherwise.
Until recently, Wasm’s reality didn’t live up to the hype. Despite the immense potential and incredible community, Wasm lacked the necessary tooling, stable interfaces and APIs to make it truly production ready. Developers who wanted to use Wasm had to become Wasm experts themselves, venturing into murky, undocumented waters. Or they could turn to specialized Wasm platform-as-a-service companies like Cosmonic or Fermyon, which offer smoother on-ramps by hiding much of the initial complexity.
Enter WASI Preview 2. Although it is only called a “preview,” don’t let the terminology fool you. WASI Preview 2 is the missing link that Wasm needed to become a viable option for production use cases. WASI, which stands for WebAssembly System Interface, is a set of standards that define a standardized way for Wasm modules to securely interact with system resources. Preview 2 represents a significant milestone in Wasm’s evolution because it provides a solid checkpoint from which developers can build with confidence knowing that the entire platform isn’t going to change out from under them.
At the heart of WASI Preview 2 is the WebAssembly Component Model. This critical piece of the puzzle provides a way to compose Wasm components into larger components, even if they were written in different languages. It’s a major step forward in terms of flexibility and cross-language compatibility. The component model defines a Canonical ABI (application binary interface) that standardizes the way components talk to each other and prevents them from accessing other components’ memories. This eliminates the largest classes of bugs and security vulnerabilities.
Another key aspect of WASI Preview 2 is the stabilization of APIs. This ensures backward compatibility in the future for Wasm applications, giving developers the confidence to build on top of Preview 2 without worrying about future disasters. It’s analogous to the way POSIX (the Portable Operating System Interface) standardized interfaces across Unix-like operating systems, making it much easier to write portable software.
But WASI intends to go further, including interfaces for all sorts of things that aren’t necessarily system resources. (Some of us in the community are trying to change what “WASI” stands for to WebAssembly Standard Interfaces to reflect this.) WASI includes HTTP as a first-class interface, a critical networking and connection capability that isn’t present in POSIX, providing better options to keep tabs on what a module is allowed to do rather than handling it as a raw socket (of course, you can do that too). It also simplifies certain aspects compared to POSIX that make more sense for WebAssembly, such as reducing from 4 to just 2 system clocks. These improvements make WASI Preview 2 a more modern and portable interface — both for web and backend apps.
The practical implications of WASI Preview 2 are huge. Previously, developers struggled to build Wasm applications outside of specialized PaaS systems that abstracted away the complexity. The lack of stable APIs and tooling made it difficult to build confidence in Wasm as a production-grade technology. Preview 2 changes all of that, paving the way for broader, even mainstream, adoption of Wasm.
The upshot of all this? When building Wasm apps, you can now pick and choose libraries from any language ecosystem, compile them into components and compose them to make one app. Teams within your organization can all develop the systems they’re responsible for with whatever tech stack they prefer. Then, through the power of the component model, developers and teams can compose them into one monolithic application with confidence that the pieces will all fit together and perform in a predictable manner.
No doubt, Wasm has always been a technology with enormous potential. Until now, that potential was stymied by gaps in tooling, stability and critical features. WASI Preview 2 fills those gaps nicely, clearing the path for Wasm to realize its promise of developer-friendliness in production environments. WASI Preview 2 and the component model should spark a rapid increase in Wasm adoption and deployment. Above all, it’s a major step forward that should make any developer or technology leader excited about the future of Wasm and encourage them to get their hands dirty building out Wasm apps.
Every major technology shift has a tipping point that drives adoption. WASI Preview 2 should be that tipping point for Wasm. It will make developing software easier, faster and more secure for developers everywhere.
