Yea most dependencies in Rust land are entirely avoidable. Most even easily (like left-pad), sometimes its hard like a wasm engine. This wasm engine is the result of us trying to avoid a dep on a wasm engine from the ecosystem. It bloated the build time of our IDE by 300% to just include it (we were just 25% of the buildtime if i include wasmtime). Now was that a good idea? I don't know but we're getting very close now to a full product whilst still compiling in release build with all deps in <10s on a new mac. I'm personally really opposed to using small convenience libraries. Just write the code you need in a 'slightly less convenient way'. Use the standard library if you can. No need to pile on say entire networking stacks if you can talk to the platform networking apis for instance.

Essentially it is: avoid all dependencies, and if you take them on, like platform libs strip them down to only what you use

For use in makepad (our Rust IDE/UI framework) as our extension-system Eddy Bruël built a new experimental spec compliant wasm interpreter that relies on sibling call optimisation to get within 4x of a wasm JIT. It has no dependencies and compiles in 2 seconds. Can ship on iOS and is very useful for low weight app extension systems

I'm the author of Stitch. Rik is somewhat overpromising: Stitch is only faster than Wasm3 on Windows (by about 15%). On Mac and Linux, it is about as fast. It does get within 4x of Wasmtime (which is the JIT I've compared it against), but only on Mac. On Linux and Windows, it gets within 8x.

You should test it on a fast CPU tho on linux, its likely faster there. As you have said its likely an instruction cache issue.

Browser apps are not only about these usecases, which are mostly a document-use-of-DOM feature. Which is fine for certain cases. However for a synthesiser UI, IDE, designtools or even a SDXL explorer flowgraph i don't really care about that. You want fast UI, with threads available to make workloads not hiccup the system. And thats what we're building with makepad. I found the stranglehold that HTML put on application developers over the years to be so demotivating i almost quit building applications that ran in a browser entirely. But luckily now we have wasm+rust+webgl/gpu and things can happen again.

It shouldnt be 'that' blurry tho, sounds like maybe you have a browser-zoom level thats not 100%. I try to deal with that, but there are browsers that mess it up (safari can for instance)

Yea we're struggling a bit with super sharp rendering on lower DPI screens. It's on our todolist.

What browser/OS are you on? Works fine here. Needs wasm+webaudio worklets and shared memory to work

Good point, i'll work on it

It's using lots of workers and SIMD. What is your OS/browser?

Wait what, that's a thing on web now? I thought simd was only on native, not wasm

I saw mention of it in the emscripten docs but haven't experimented yet:

https://emscripten.org/docs/porting/simd.html

Thanks :) All the work of 'this is not rocket science'