I've been building my entire back-end with WASM for several months now, and I can share some thoughts: 1. WASM on the Web: Just don't do it. It's not there yet

I've been building my entire back-end with WASM for several months now, and I can share some thoughts: 1. WASM on the Web: Just don't do it. It's not there yet. WASM actually has overhead compared to regular JavaScript, so it only makes sense for specific operations like video transformations. Otherwise, you're better off with a React stack. React isn't inherently slow—it just makes it easy to write slow code. Plus, most WASM frameworks (like Yew) are still immature with limited ecosystem support. 2. "Lightweight virtualization" sounds great in theory, but reality is different. The promise is "compile once, deploy everywhere," but if you can deploy everywhere, you probably can't deploy anywhere effectively. That's because once you remove networking, time and multi-threading, you are left with pretty much nothing. There is also a no consensus standard. There is WASI but it's a kind of a work-in-progress. Implementation will depend on your host. I went with Cloudflare Workers, which meant learning their specific environment. The problem with these newer platforms is they don't have the documentation or community support you get with something like Linux. While Cloudflare runs workers on V8 at the edge (which helps), they have restrictions that you only discover as you go. For example, there's no "time" concept available inside a Cloudflare Worker's execution context. 3. Target support is genuinely terrible. Don't assume libraries will compile to wasm32-unknown-unknown—assume the opposite. Most libraries don't separate computational tasks from networking, and Rust's async ecosystem (Tokio) does not play well with WASM, breaking your code. I've had to fork two libraries and submit patches to several others. As a solo developer, this maintenance burden becomes expensive. Making libraries WASM-compatible could be a full-time job. 4. On Scalability: Just because you have a worker, doesn't translate to having "infinite" scalability. Here's the thing - as soon as your application does anything meaningful, you need state. Now your "infinitely scalable" architecture is only as scalable as your state (ie: RDS database) can handle. There isn't really a good server-less database offering and Databases are not the only thing that will bottleneck you here (ie: I have a keycloak server for signups). > The aim is to build systems with the fine-grained interoperation of shared libraries, specified in a way to allow isolation but without requiring the overhead of an operating system process or a container. Add time and networking to this mix, and you've basically described an operating system. > For plug-in and extension use cases, Wasm can be a good option if the host needs isolation from the guest This is actually WASM's sweet spot. These extensions run in the host environment (like Shopify), and WASM provides JavaScript-like capabilities with language choice and better isolation. > The cloud Wasm space is a bit of a Wild West It absolutely is—still in its infancy with little interest from major players to adopt this model. In conclusion, I'm still torn on the whole thing. Some mornings I wake up to a broken build and wonder what the hell I was thinking. But then there are moments when everything clicks. My worker—27k lines that squeeze down to 3MB—feeling like a jet engine. The constraints make you want to tear your hair out; but they make you think twice about everything. You can't just throw another dependency at a problem. You need to consider and weigh in any additional code. The worker model makes the request flow clearer and gives you a better understanding of your application life-cycle. shamless plug (ps: it's nowhere near ready): https://codeinput.com https://codeinput.com