This mirrors my experience of using wasm to speed up the front end of a very data intensive, real-time search application. It was like every improvement was on

This mirrors my experience of using wasm to speed up the front end of a very data intensive, real-time search application. It was like every improvement was only marginal, and all of the wasm costs kind of nullified the improvements (especially when combined with the cognitive overhead of a more complex implementation). I never deployed any solutions because it wasn’t compelling enough to introduce the massive change and complexity. Overall I think I spent around 4 months revisiting, tinkering, reading, trying to find a way to squeeze out enough performance to make it worth it. I’d love to find the right opportunity to use it, but like the author discovered, it’s really difficult. The effort put into making the wasm solution would have been far more valuable learning to manage ui state slightly more efficiently, improving the data structures, finding places to reduce work, etc. in the typescript code. One thing I wondered: if you work in a monorepo, you might be able to leverage backend code reuse very easily for frontend if you’re using (or able to use) shared data structures across your stack. That was one thing I thought had real potential in terms of developer ergonomics alone. Just keep data in wasm until it’s UI-ready. Don’t type the same data twice, don’t introduce a complex api boundary. Rust is far better at some things than typescript, so I thought that might be worth pursuing even if the performance was only marginally better. Having said that, I thought a lot of things would be helpful and good with wasm and I was wrong, so that idea could be bad too.