What has changed, however, is the volume of conversation about WASM. As WASM has taken the initial steps towards a potential role as a critical piece of enterprise infrastructure, discussion of the technology has spiked both in the community at large and within the conversations RedMonk has with its participants.
The broadest market impact, however, would come from WASM PaaS-like abstractions capturing workloads at scale. While vendors like Cosmonic and Fermyon were built around WASM, however, and others like Cloudflare, Fastly and Vercel have spun up that capability – or in Fastly’s case, hired an entire team out of Mozilla – there are some obstacles between WASM and a role of outsized importance. The documentation could use some attention, and while it’s not strictly necessary, it would be useful to have standardized orchestration mechanisms for large-scale WASM deployments. Fermyon is using Nomad, and there are other projects targeting the problem, but it would be useful for a standard means of orchestration to emerge. More pressingly, however, is the need for a standardized component model. As described by Charlie Marsh:
There’s no standardized component model for WebAssembly right now, so in order to run on any sort of hosted WebAssembly platform, you have to implement module-side code (source). You see this with Fermyon, where you have to write your code using their Spin framework. You also see this with Fastly’s Compute@Edge, where you have to implement fastly_http_req and fastly_http_body to make your WebAssembly code compatible with their interface (source). Maybe this is fine, I just expected something more generic.