3 ms·
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 need
by 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 agoi swear, some people hate rust as much as the comment sections claim rust people are fanatics
- deleted 2y ago[deleted]
- notpushkin 2y agoI’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 agohttps://crates.io/crates/sledgehammer#:~:text=Why%20is%20it%20fast https://crates.io/crates/sledgehammer#:~:text=Why%20is%20it%...
- whitehexagon 2y agoI 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.