4 ms·

I was slightly worried it would be one of those “render to canvas” frameworks (which are an accessibility nightmare and are ever so slightly broken), but that’s

I was slightly worried it would be one of those “render to canvas” frameworks (which are an accessibility nightmare and are ever so slightly broken), but that’s not the case here! Looks like WASM – DOM interop is finally fast enough for this to work. 32 MB binary is a big no-no though.

kolanos 2y ago
Looks like it was compressed to 4MB, but still.
- nicoburns 2y ago
  Yeah, but with most JavaScript frameworks (and even Rust compiled to WASM), 4MB (at most!) would be the size of the uncompressed bundle.
- aledalgrande 2y ago
  Figma is much more than that and lots of people use it daily
- theanonymousone 2y ago
  Coincidentally, I just checked the LinkedIn page of a colleague, and Vivaldi said it was loading ~30MB of data for that.
golergka 2y ago
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.
- notpushkin 2y ago
  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.
  - gedw99 2y ago
    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.
whitehexagon 2y ago
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.
- J_Shelby_J 2y ago
  i swear, some people hate rust as much as the comment sections claim rust people are fanatics
  - deleted 2y ago
    [deleted]
- notpushkin 2y ago
  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?
  - qvq 2y ago
    https://crates.io/crates/sledgehammer#:~:text=Why%20is%20it%20fast https://crates.io/crates/sledgehammer#:~:text=Why%20is%20it%...
  - whitehexagon 2y ago
    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.
WhyNotHugo 2y ago
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.

kolanos 2y ago

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

nicoburns 2y ago
Yeah, but with most JavaScript frameworks (and even Rust compiled to WASM), 4MB (at most!) would be the size of the uncompressed bundle.
aledalgrande 2y ago
Figma is much more than that and lots of people use it daily
theanonymousone 2y ago
Coincidentally, I just checked the LinkedIn page of a colleague, and Vivaldi said it was loading ~30MB of data for that.

golergka 2y ago

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.

notpushkin 2y ago
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.
- gedw99 2y ago
  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.

whitehexagon 2y ago

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.

J_Shelby_J 2y ago
i swear, some people hate rust as much as the comment sections claim rust people are fanatics
- deleted 2y ago
  [deleted]
notpushkin 2y ago
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?
- qvq 2y ago
  https://crates.io/crates/sledgehammer#:~:text=Why%20is%20it%20fast https://crates.io/crates/sledgehammer#:~:text=Why%20is%20it%...
- whitehexagon 2y ago
  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.

WhyNotHugo 2y ago

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.