-
Good point! This is the hard work that people are undertaking right now.
Things are going to change a little bit with the introduction of Preview3 (the flagship feature there is async without function coloring), but you can look at the core interfaces:
https://github.com/WebAssembly/WASI/tree/main/wasip2
This is what people are building on, in the upstream, and in the bytecode alliance
You're absolutely right about embeddings being varied, but the standard existing enforces the expectations around a core set of these, and then the carving out of embeddings to support different use cases is a welcome and intended consequence.
WASI started as closer to POSIX now, but there is a spectacular opportunity to not repeat some mistakes of the past, so some of those opportunities are taken where they make sense/won't cause too much disruption to people building in support.
-
CodeRabbit
CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
-
> …but if WASI is simply adding more options without taking anything away then my point above is moot :)
Didn't take it as such! The ability to avoid function coloring does not block the implementations of high-threads/high-memory applications, once an approach to threading is fully reconsidered. And adding more options while keeping existing workflows in place is definitely the goal (and probably the only reasonable path to non-trivial adoption...).
How to do it is quite involved, but there are really smart people thinking very hard about it and trying to find a cross-language optimal approach. For example, see the explainer for Async:
https://github.com/WebAssembly/component-model/blob/main/des...
There are many corners (and much follow up discussion), but it's shaping up to be a pretty good interface, and widely implementable for many languages (Rust and JS efforts are underway, more will come with time and effort!).
-
AvaloniaVisualBasic6
A recreation of the classic Visual Basic 6 IDE and language in C# with Avalonia
How else am I supposed to use a Visual Basic 6 clone written in C# in my browser?
https://bandysc.github.io/AvaloniaVisualBasic6/
https://github.com/BAndysc/AvaloniaVisualBasic6
WebAssembly brings all languages to the browser and that's a good thing.
I can write applications for the desktop in any language, I should be able to do the same thing in the browser.
WebAssembly makes that possible.
-
The Orca project is attempting to do exactly that: https://github.com/orca-app/orca
-
> The problem is that in WASM-land we're heading towards WASI and WAT components, which is similar to the .NET, COM & IDL ecosystems. While this is actually really cool in terms of component and interface discovery, the downside is that it means you have to re-invent the world to work with this flavor of runtime.
At the application level, you're generally going to write to the standards + your embedding. Companies that write embeddings are encouraced/incentivized to write good abstractions that work with standards to reduce user friction.
For example, for making HTTP requests and responding to HTTP requests, there is WASI HTTP:
https://github.com/WebAssembly/wasi-http
It's written in a way that is robust enough to handle most use cases without much loss of efficiency. There are a few inefficiencies in the WIT contracts (that will go away soon, as async lands in p3), but it represents a near-ideal representation of a HTTP request and is easy for many vendors to build on/against.
As far as rewriting the world, this happens to luckily not be quite true, thanks to projects like wasi-libc:
https://github.com/webassembly/wasi-libc
Networking is actually much more solved in WASI now than it was roughly a year ago -- threads is taking a little longer to cook (for good reasons), but async (without function coloring) is coming this year (likely in the next 3-4 months).
The sandboxing abilities of WASM are near unmatched, along with it's startup time and execution speed compared to native.
-
> The problem is that in WASM-land we're heading towards WASI and WAT components, which is similar to the .NET, COM & IDL ecosystems. While this is actually really cool in terms of component and interface discovery, the downside is that it means you have to re-invent the world to work with this flavor of runtime.
At the application level, you're generally going to write to the standards + your embedding. Companies that write embeddings are encouraced/incentivized to write good abstractions that work with standards to reduce user friction.
For example, for making HTTP requests and responding to HTTP requests, there is WASI HTTP:
https://github.com/WebAssembly/wasi-http
It's written in a way that is robust enough to handle most use cases without much loss of efficiency. There are a few inefficiencies in the WIT contracts (that will go away soon, as async lands in p3), but it represents a near-ideal representation of a HTTP request and is easy for many vendors to build on/against.
As far as rewriting the world, this happens to luckily not be quite true, thanks to projects like wasi-libc:
https://github.com/webassembly/wasi-libc
Networking is actually much more solved in WASI now than it was roughly a year ago -- threads is taking a little longer to cook (for good reasons), but async (without function coloring) is coming this year (likely in the next 3-4 months).
The sandboxing abilities of WASM are near unmatched, along with it's startup time and execution speed compared to native.
-
Or even the other direction, upward toward full vms, or hybrid: https://github.com/kubevirt/kubevirt/blob/v1.4.0/docs/archit...
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
1Password actually bundles it with everything they ship (browser, desktop, even their golang cli): https://github.com/1Password/onepassword-sdk-go/tree/v0.1.7/... and then use extism to cross over its boundary https://github.com/1Password/onepassword-sdk-go/blob/v0.1.7/...
They compiled their rust libraries to wasm and it allows reuse of those rust bits across everything
-
slint
Slint is a declarative GUI toolkit to build native user interfaces for Rust, C++, or JavaScript apps.
> I wonder if someone could make a decent cross-platform GUI toolkit to save us from the horribly slow Electron-hell we've carved out for ourselves.
https://github.com/slint-ui/slint
-
You can use something like https://github.com/google/gvisor as a container runtime for podman or docker. It's a good hybrid between VMs and containers. The container is put into sort of VM via kvm, but it does not supply a kernel and talks to a fake one. This means that security boundary is almost as strong as VM, but mostly everything will work like in a normal container.
E.g. here's I can read host filesystem even though uname says weird things about the kernel container is running in:
$ sudo podman run -it --runtime=/usr/bin/runsc_wrap -v /:/app debian:bookworm /bin/bash -
For folks interested in the current state of the art on sandboxing, here is a stab one of my former coworkers did:
https://github.com/firedancer-io/firedancer/blob/main/src/ut...
He researched chromeos process virtualization, moby (docker upstream), and chrome tab isolation. It’s all done ebpf magic on top of seccomp at its core.
-
extism
The framework for building with WebAssembly (wasm). Easily load wasm modules, move data, call functions, and build extensible apps.
Application plugins could also be wasm. That lets plugin authors write in any language they want and have their plugin work. That's the idea behind the Extism framework:
https://extism.org/
-
> the downside is that it means you have to re-invent the world to work with this flavor of runtime.
This is at least one of the reasons we've been building thin kernel interfaces for Wasm. We've built two now, one for the Linux syscall interface (https://github.com/arjunr2/WALI) and one for Zephyr. A preliminary paper we wrote a year or so back is here (https://arxiv.org/abs/2312.03858), and we have a new one coming up in Eurosys 25.
One of the advantages of a thin kernel interface to something like Linux is really low overhead and low implementation burden for Wasm engines. This makes it easier to then build things like WASI just one level up, compiled against the kernel interface and delivered as a Wasm module. Thus a single WASI implementation can be reused across engines.
-
I run my golang on car workers.
It does not work with wasi.
I just use a simple driver:
https://github.com/syumai/workers
Wasi is so painful that I just write all my golang using stdio and have a shim per runtime. Web browser, Cloudflare, server ( with wazero ).
The new go:wasmexport might be useful in go 1.24 but I highly doubt by it.
-
Fully agree with your point here, but wanted to point out that including C dependencies is actually one of the biggest reasons why Python support is hard for WebAssembly too.
Bolstering your point -- smart-and-hardworking people are working on this, which results in:
https://github.com/bytecodealliance/componentize-py/
which inspired
https://github.com/WebAssembly/component-model/blob/main/des...
which is made concrete by
https://github.com/dicej/wasi-wheels
-
Fully agree with your point here, but wanted to point out that including C dependencies is actually one of the biggest reasons why Python support is hard for WebAssembly too.
Bolstering your point -- smart-and-hardworking people are working on this, which results in:
https://github.com/bytecodealliance/componentize-py/
which inspired
https://github.com/WebAssembly/component-model/blob/main/des...
which is made concrete by
https://github.com/dicej/wasi-wheels
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
