While I think that with their current choice for the runtime will hit some limitations (aka: not really full Python support, partial JS support), I strongly believe using Wasm for sandboxing is the way for the future of containers.
At Wasmer we are working hard to make this model work. I'm incredibly happy to see more people joining on the quest!
Browserpod is great, been following it for a bit. Keep the good work up!
The main issue that I see with Browserpod is very similar to Emscripten: it's designed to work mainly in the browser, and not outside.
In my view, where Wasm really shines, is for enabling containers that work seamlessly in any of this environments: browsers, servers, or even embedded in apps :)
It is true that BrowserPod is currently focused on browsers environment, but there is nothing preventing the technology from running on native as well. It would requite some work, but nothing truly challenging :-)
Appreciate your support! We deliberately chose a limited runtime (quickjs + some shell applets). The tool parameter constraint enforcement was more important to us than language completeness. For agent tool calling, you don't really need NumPy and Pandas.
Wasmer is doing great work—we're using wasmtime on the host side currently but have been following your progress. Excited to see WASM sandboxing become more mainstream for this use case.
Fair point. We get around this by "yielding" back from the Wasm runtime (in a coroutine style) so that the "host" can do network calls or other IO on behalf of the Wasm runtime. But it would be great to do this natively within Wasm!
We implemented all the system calls necessary to make networking work (within Wasm), and dynamic linking (so you could import and run pydantic, numpy, gevent and more!)
Great analysis. I'm Syrus, from Wasmer, and I've been working on WebAssembly professionally for the last 7 years (we are, in fact, the first Wasm-first company!)... hopefully my point of view would be useful to read!
Why things are not as heated? Simply, because many of the big players are no longer doing the big bets on the technology, nor they are spending any marketing on making it successful. Mainly because most of their bets have been unsuccessful: WASI, Component Model.
Many of the small players that raised money on the space either died or ended being acqui-hired by bigger players. The only ones that survive is the ones that truly understand is that tech doesn't matter a thing, is the product (what are you enabling with WebAssembly).
In my view, this happens because there's a great mismatch between technical capabilities and the go-to-market skills that bringing the tech to the masses requires.
The developers that tend to be technically great and understand the value of WebAssembly, are usually not as good on Go To Market to make it successful. For example, WASI proponents wanted to completely break the POSIX model (because in their view, is completely wrong... and they are partially right!). But they don't only want Wasm to succeed... they also want their mental model of new Operating System calls to go along with it (thus, you tie the success of one, to the success of another).
AI only amplifies the Go To Market skills even further, by accelerating tech even more. When your MOAT is fully built around the tech but there's nothing that sustains it (a product), then you have an issue. The market is what sustains it, nothing else. People in the ecosystem cared way more about politics (creating a working group to control other companies), than they cared about creating something that many people could use tomorrow.
At Wasmer, it took us a bit of time to understand this, but overtime we have been able to improve our skills to continuing capturing value from it.
So, it's possible to create something successful with WebAssembly.
You just need to make something people want (tl;dr: is not the tech!)
> Mainly because most of their bets have been unsuccessful: WASI, Component Model.
Can you expand on that? I've only been using wasm for web (and the current status quo of JS bindings to the DOM is working just fine for me) so I haven't been following that strongly, but for the last couple months I was under impression that people are still trying to push WASI.
WASI in their first attempt has been a success (what now is called wasip1). wasip2, p3, are tied into the component model.
I'd say that wasip1 has been successful, but not any future version.
You can check which version is the most popular just by looking at the Rust WASI crate versions and how much downloads each one has:
reply