Fermyon Blog

Sandboxing. The new way of doing containers.

I'd think of it as plugins everywhere, like L7 proxies [1]. The code for a network filter could be reloaded in the server upon detection to a configuration change. I believe the startup mad dash is on to capture who is going to run the container runtimes, and host the plugin repositories.

So my guess is that Fermyon Technologies with Spin could be looking to follow the Vercel with NextJS model where everything will be open source and runnable from the development runtime, but there eventually will be features like Edge Functions [2] in five years that will only be available when you deploy to their hosted service. They'll likely work towards that with web services with Spin [3]
and CMS with Bartholomew [4] for starters. Instead of everything linked together in a NodeJS app directly, your code will run from a WASM library in a sandbox.

But my guess about the Vercel model could be slightly wrong after checking out their solid founding team [5] -- the bios emphasize the WASM and Kubernetes worlds. The problem if it is something like the Docker model is that the standard will just be made with the big players like OpenContainer [6] and the enterprise business sold off [7], and/or folded into one of the cloud infra players (with the data centers).

[1] https://github.com/proxy-wasm/spec

[2] https://vercel.com/docs/concepts/functions/edge-functions

[3] https://spin.fermyon.dev/

[4] https://github.com/fermyon/bartholomew

[5]…

While I don't necessarily agree with the unnecessary, unsupported, casual, & cheap (provided with zero substantiating/contestable support) contempt culture here ("unshackle the web from the mess that is JavaScript", "places that don't really need these problems to be solved")...

WebAssembly component-model is being developed to allow referring to and passing complex objects between different modules and the outside world, by establishing WebAssembly Interface Types (WIT). It's basically a ABI layer for wasm. This is a pre-requisite for host-object bridging, bringing in things like DOM elements.

Long running effort, but it's hard work and there's just not that many hands available for this deep work. Some assorted links with more: https://github.com/WebAssembly/component-model https://www.fermyon.com/blog/webassembly-component-model https://thenewstack.io/can-webassembly-get-its-act-together-for-a-component-model/

A preview-2 should be arriving sometime somewhat soon.

It's just hard work. It's happening. And I think the advantages Andy talks to here illuminate very real reasons why this tech can be useful broadly. The ability to have plugins to a system that can be safely sandboxed is a huge win. That it's in any language allows much wider ecosystem of interests to participate, versus everyone interested in extending your work also having to be a java or c++ or rust developer.

Owner of the purposefully controversial opinion here :) Looks like its proven to be very controversial, which was the stated goal of the podcast segment :)

For context, I had just returned from KubeCon + CloudNativeCon EU in Amsterdam. I had a chance to talk to many of the great folks pushing the WASM ecosystem forward, and there certainly seemed to be a large amount of momentum behind using WASM in the server space and at the edge. I'd had a great time learning from the folks at various open-source projects / companies pushing WASM forward:

- Bytecode Alliance (shout out to Bailey)

- https://cosmonic.com/

- https://www.fermyon.com/

- https://wasmcloud.com/

At DevCycle we are using WASM to help share core Feature Flag decisioning code across our Cloudflare Worker APIs and our server SDKs for local decisioning. We've learned a bunch about compatibility / optimizing performance / limitations that I'm happy to chat about in more detail. But we are generally excited for the future of WASM, especially for the new features coming: Component Model / Threading / Garbage Collection changes / Networking.

If you are looking for how to use WASM Components to replace container-based runtimes, look at the companies linked above.

It is happening. Leptos is an example: https://www.leptos.dev/

Dioxus is another: https://dioxuslabs.com/

C# with Avalonia for a different use case: https://avaloniaui.net/

Avalonia solitaire demo: https://solitaire.xaml.live/

Avalonia Visual Basic 6 clone: https://bandysc.github.io/AvaloniaVisualBasic6/

Blazor can run as WebAssembly on the client side if you choose that runtime mode: https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blazor

Beyond the browser, Wasmer does WebAssembly on the serverside: https://wasmer.io/

Fermyon too: https://www.fermyon.com/

Extism is a framework for an application to support WebAssembly plugins: https://extism.org/

> And for just that give up all the freedom docker runtimes give us?

Constraints give you freedom because they allow you to make guarantees. Checksums, reliable test suites, and good software abstractions are all examples.

> I don’t want to be forced to use go or rust - maybe I’d like to use bash, node or even the jvm depending on the problem I need to solve.

Those are runtimes, not languages. Here's a list of languages that compile to WASM: https://www.fermyon.com/wasm-languages/webassembly-language-support

IMO bash wouldn't make sense, but Java and Kotlin are there, as well as AssemblyScript, which is basically TypeScript.

For deploying Rust servers, I use Spin WASM functions[1], so no Docker / Kubernetes is necessary. Not affiliated with them, just saying. I just build the final WASM binary and then the rest is managed by the runtime.

Sadly, the compile time is just as bad, but I think in this case the allocator is the biggest culprit, since disabling optimization will degrade run-time performance. The Rust team should maybe look into shipping their own bundled allocator, "native" allocators are highly unpredictable.

[^1]: https://www.fermyon.com