As the latest web technology to catch fire, Webassembly (abbreviated to Wasm) is considered by many a “can’t miss” proposition. Proponents rave about the performance, which is lightning-fast, and the security model, which is “least privilege” from the ground up. Near-instant startup times of WebAssembly processes are a big benefit as well. But, often missing from the list of major benefits is true portability. I’d argue that portability is on par with, if not more important, than all the other benefits.Why? Because robust portability is the ultimate killer app.Untold tens of billions are wasted each year on the act of “porting,” made unpleasant and expensive by the requirement for multiple build pipelines for different targets. Every DevOps team knows what porting hell is: trying to have an opinionated app run on multiple clouds or trying to run the same process and code in multiple serverless environments.Portability is why the dominant SaaS model emerging today is a distributed cloud where a technology company abstracts away the multicloud complexities to allow customers to just write once and run everywhere. With portability comes resilience, agency and bargaining power on price.For developers, DevOps and platform teams, true portability has long been a Holy Grail, often promised but never fully delivered. We heard it with Java, then with containers and then in serverless. Write once, run anywhere. Pure bliss. For various reasons across time and these examples, unfettered portability never emerged.But now comes WebAssembly. It is the ultimate tabla rasa, a chance to rewrite almost everything we do in compute and infrastructure. If we collectively manage the development of WebAssembly to keep the core runtime and standards for WebAssembly interfaces and APIs free of proprietary elements and unnecessary cruft, WebAssembly might be our best chance for true portability — not only of compute, but also of networking and data connectivity.Portability rhymes with agility and flexibility. It is the flip side of polyglot architectures and applications that enable developers to write in the language of their choice. It minimizes toil, improves security and radically enhances the developer experience. In theory, WebAssembly is better positioned to fulfill this dream than any technology to date, because cross-platform portability and polyglot capabilities were explicit design goals of WebAssembly from the beginning.Containers offer more portability than application stacks tied to specific hardware platforms and architectures. But in reality, containers are hardly portable. For example, consider the pain for cross-architecture builds for Intel versus Arm.Operating system-level virtualization means containers bundle the entire stack including networking and OS layers. This is bulky and hard to move without considerable tuning. Containers also share a host kernel, which requires additional security configurations that are highly dependent on platform and underlying infrastructure. While containers do make cross-cloud portability easier, they still require underlying containerization software. This limits edge compute, on-device and other emerging compute possibilities.Serverless doesn’t carry the burden of the full OS and networking stack, but serverless functions are generally tied to specific cloud providers with underlying proprietary functionality and code. Moving pure functions from one cloud to another is no picnic. Serverless does abstract infrastructure, but it lacks a robust plug-in interface that can be used to provide granular control and more bespoke tuning of the environment.WebAssembly suffers neither of these extremes. Unlike most serverless offerings, WebAssembly is not tightly bound to specific services. Yes, there are excellent open source serverless stacks out there, but all come with considerable pre-baked assumptions.Just as the browser is designed for strict adherence to open standards (rendering HTML to the same output), so is WebAssembly designed to run all code the same, regardless of the underlying platform or hardware. It’s a runtime first and foremost, with all other functionality applied outside the sandbox via plug-ins.In practice, WebAssembly today lacks some of the key tooling that developers need to easily write and run it. WebAssembly also does not have widely accepted standards for compatible runtimes. The risk is that companies seeking to build WebAssembly-friendly SaaS platforms and application wrappers will add proprietary code into WebAssembly and make developers’ lives easier while simultaneously forcing developers to retune and repackage WebAssembly apps for different environments.In other words, no portability. Once this is set in motion, reversing gears would be hard. We could end up with a WebAssembly Tower of Babel, not unlike the compatibility and portability issues we see even today with container applications.Fortunately, WebAssembly is strongly biased toward the best solution: the plug-in. WebAssembly plug-ins already are widely used and deployed to add functionality such as reverse proxies, data handling and IDE integration. Just as VSCode has built the biggest and most successful IDE ecosystem on the back of robust plug-in support, WebAssembly would find the same benefit with plug-in directories, plug-in registries and more.This sounds simplistic and obvious. But it will work best if we keep the WebAssembly standard, compilers and all other core WebAssembly elements exclusively focused on runtime execution and free of additional code and cruft. Just as Unix has thrived over time by prioritizing compartmentalization and small tools doing modular jobs very well, WebAssembly would benefit from the same principle.The WebAssembly community is well aware of the trade-offs inherent in adding more functionality to core WebAssembly. And none of this is to say that companies and projects building WebAssembly tooling that aims to add more functionality inside the sandbox have ill intentions. They are trying to solve problems and make it easier for developers in the near term.But over the longer term, developers would benefit the most from a tightly defined, minimalist WebAssembly core. Specific benefits would include simpler testing, relatively painless dev-to-prod mobility, least privilege and capability security, even more polyglot capabilities and, of course, total portability.WebAssembly is here, and it’s going to be huge, following in the footsteps of containers. If we stay strong to our principles of simple, contained, lightweight and secure, then WebAssembly will eclipse containers and possibly everything else, becoming the runtime that runs everywhere, on anything. And developers will love it.Community created roadmaps, articles, resources and journeys fordevelopers to help you choose your path and grow in your career.