Looks like it was compressed to 4MB, but still.

Yeah, but with most JavaScript frameworks (and even Rust compiled to WASM), 4MB (at most!) would be the size of the uncompressed bundle.

Figma is much more than that and lots of people use it daily

Coincidentally, I just checked the LinkedIn page of a colleague, and Vivaldi said it was loading ~30MB of data for that.

Not a fan of this bundle size, but it's not a web store landing page — it's a professional application, and it's users are likely to use it extensively through their day, and all hundreds of navigation events and new tabs will (if handled correctly) hit the same cached bundle.

It’s a good point, but keep in mind that’s 32 MB of code: you can cache it, but you still have to parse and initialize it for every tab. (It might not be as bad as it sounds, WASM is lighter in this aspect than JS; but it’s still a good proxy for startup performance IMO.)

It should work well for applications with longer session size, like Figma: you open a project one time and work on it for hours. I’m not sure if that’s the case with Dagger Cloud: you might be looking at a single trace, or compare dozens of builds throughout the day. The post only claims “better overall performance and lower memory usage”, but without any numbers it’s hard to tell anything.

I use golang WASM and use web workers and shared workers with a service worker.

This means that a new tab does not reload the whole thing each time.

Once you get it going it’s easy to build large complex systems.

I also struggled with the binary output size of Golang WASM, and that it was growing with each version. Someone recommended TinyGo, and although I haven't needed it for a couple years now, at the time the WASM binary output size was much better.

Now I am settled on Zig/WASM, which gets me pretty close to C/WASM combo i.e. tiny. The JS bridge has some overhead, but I've rewritten most of that and it works good enough for canvas 2D/3D or even DOM. It would be nice to ditch the JS bits, and I suspect the compositors all-the-way down are probably hitting my 2D performance.

I’ve been looking at Zig for some time, too. Perhaps I should give it a go!

Any particular tricks on making bridged DOM fast?

I use a custom API on the JS side, and making the most of the shared memory for strings. For widget creation within DOM I have small API wrappers on the JS side to avoid too much bridge crossing with attribute sets/gets.

For 2D/3D moving the canvas animation loop to the JS side helped.

So far the html (inc custom JS API) comes in at 20KB, and my wasm around 80KB (SVG based UI with a small embedded font).

Not sure how the latest Zig compares, but I'd be quite happy stuck on this older version for this project because it seems very stable.

i swear, some people hate rust as much as the comment sections claim rust people are fanatics

I had the same worry: that they'd be rendering everything into a canvas. It's very neat to see that the WASM<>DOM interop is there now, and they render actual native elements. Even inspecting the DOM it's quite readable (far easier to read that I've seen React produce).

OTOH, Rust solutions have been pretty disappointing so far; usually relying on macros (which are a pain to write, debug or maintain in any way) and lots of DSLs (which negate the value of any development tools).

The binary size for this approach is a big issue, but assuming that it can be decreased, I'd think that go can end up being a very viable candidate in this space.