>...if you are building an organization to create a web experience, generally speaking, you would rather pull from the deeper pool of JS developers than the more rarified C++/Wasm skill set

This is ultimately answering the reason why above, but it's important to point out the most critical parts of Figma and the reason Figma is worth what it is are the WASM/GPU accelerated parts which make all the interaction snappy and fluid, even the multiplayer stuff is downstream from this.

But also because it's a huge company now and a lot of the developers they hire could never create those critical parts of course the rest of it will bloat out as developers justify their existence.

https://orca-app.dev/

The tech community simply wants DOM access for web apps, but the committee is focused on trying to effectively rewrite the JVM in Rust because Rust seems trendy these days.

So the web features languish while the committee still can't agree on how to send strings between two functions on Linux. And the committee moves at a slower pace than the federal government.

That led me to wasmCloud[1]. As the article says, Wasm on the server isn't a winner yet, but it has a chance.

[1] https://wasmcloud.com

The most notable thing about PS in the browser is web components, not WASM.

Where can one look at that breakdown?

As a result, with a small team we can make a much prettier and slicker app; and it's easy for everyone to be "full stack" without the learning curve that comes with two languages. It's also nice to share code between the server and browser, for things like contracts and small bits of logic that are easily isolated.

One of the more frustrating aspects of WASM via C# is the slow load time because the binary is large. Another frustrating aspect is that, for tight integration with the DOM, it still is best to use JavaScript. As a result, we end up spending time writing wrappers for "best of class" JavaScript libraries instead of using C# libraries.

---

In our case, with hindsight, I think server-side Blazor (with pure JavaScript or TypeScript for logic that needs to happen in the browser,) would be better for our purposes. (It basically moves a lot of the state that would be in the browser to the server. This is really helpful for small teams.) There's reasons why I don't think we'll switch any time soon.

https://bandysc.github.io/AvaloniaVisualBasic6/

Amazon switched the Prime Video app to WebAssembly and doubled its performance. They support 8,000 device types: https://www.amazon.science/blog/how-prime-video-updates-its-...

A recent talk on it with transcript: https://www.infoq.com/presentations/prime-video-rust/

The causual inference here is almost certainly incorrect. According to Chrome Blog [0], WebSQL turned out to be a non-starter as early as November 2010, which is before Webassembly was released, and before it became known that SQLite could be ported to Webassembly to run in web browser.

[0] - https://developer.chrome.com/blog/deprecating-web-sql

Nailed it. We have JS in the browser, and (particularly with TS) it's a great language for building applications on the web. What's great about WASM is the interop layer we have now between other systems. Our company has a mountain of legacy C++, encoding many years of hard-won business logic, and the ability to tap into that on the frontend (locally, in-client) has been amazing. No more hacky transpilation or maintaining separate codebases; just write your FFI and compile the binary to WASM.

If you want to build something like libpng (or a myriad of other C libraries,) you need setjmp/longjmp. Not really a huge problem: Emscripten can handle this, it just needs a tiny bit of help via host functions. You can also use Wasm Exception Handling instead, in which case you don't need any hacks on the host side.

So far this sounds pretty good, but actually it isn't, because:

- Wasm Exception Handling is still not part of the standard. They are supported by browsers and runtimes based on browsers, but they are unsupported by lots of other runtimes (Wazero doesn't seem to support them, for example.)

- When you're using Emscripten outside of a browser, you can use the Emscripten method for sjlj support even in a "standalone" build, calling into some simple host functions, which is handy. The problem is... standalone builds with Emscripten don't really work that well. A lot of the syscalls don't really go anywhere: https://github.com/emscripten-core/emscripten/blob/main/syst...

A non-standalone build is possible, but even though Emscripten does use WASI for many things automatically, a lot of host support is required to make this work properly, so outside of a browser environment I reckon this will take a lot of work, and it seems also that it will be hard to properly implement those functions in many of the standalone Wasm runtimes.

You can compile with a Clang/WASI toolchain instead, which will implement much more of the syscalls via WASI, but I don't think this supports the Esmcripten method for handling Wasm Exception Handling, which means you need to have a runtime with Wasm Exception Handling support.

I guess the Clang/WASI toolchain is doing the right thing here, but it's still somewhat frustrating that Wasm Exception Handling is still not a part of the standard or many of the non-browser runtimes.

Um, yes it does? Sure, you have to set some single-source or whatever flag in some header, but it works just fine - I've tested it myself.

Accessing browser native classes is still an open issue - in fact, you have to go through JS to do anything, with all the associated performance issues. I don't get it why it's so bad - for every native JS class you find on MDN, there's an equivalent C++ class in the Chrome codebase, which somehow gets bound to the JS JIT. Couldn't we expose all the API through a marshalling/validation layer? Memory leaks are a non-issue, since you can leak native objects in both JS and in C, with the only difference being that in JS, the object is still reachable through a gc root.

Another huge issue is the crappy multithreading support. First, the multithreading solution of JS workers + SharedArrayBuffer is horrible, second you aren't allowed to do it without draconian and impractical security measures, due to the security theather around side channel attacks. Which makes running heavy apps, like modern video games, practically impossible.

I remember Epic demoing Unreal in the browser in the early 2010s and a lot of people predicted that in the future, most games will be playable via a website. Yeah, that didn't come to pass.

Instead of becoming the default way of writing and distributing web apps, with the convenience of web deployment and the power of real desktop apps, it became a curiosity and a way of gaining tech clout.

This is more about monetization and less about technology, and nobody has figured out how to monetize web games beyond hyper-casual 2D games. And you don't need WASM to move a handful 2D sprites around.

Personally I'm quite happy what WASM allows me to do, e.g. the browser has become "just another runtime target" for my C/C++ hobby projects:

- https://floooh.github.io/sokol-html5/

- https://floooh.github.io/tiny8bit/

- https://floooh.github.io/doom-sokol/

...also the actual problem to run game-y stuff in browsers is not WASM, but the terrible state of web APIs, WebGL and WebGPU are both quite okay-ish, but beyond that it's an absolute mess (but OTH, people also cope with game development for Android, which is even worse).

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

I'm trying to use that through Rust on ESP32 with "wamr" but so far I've had quite a few compilation and runtime issues

if someone has some experience with that I'm interested :)