We rewrote our Rust WASM parser in TypeScript and it got faster
1–10 of 239 posts
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#2The real win here isn't TS over Rust, it's the O(N²) -> O(N) streaming fix via statement-level caching. That's a 3.3x improvement on its own, independent of language choice. The WASM boundary elimination is 2-4x, but the algorithmic fix is what actually matters for user-perceived latency during streaming. Title undersells the more interesting engineering imo.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#3The real win here isn't TS over Rust, it's the O(N²) -> O(N) streaming fix via statement-level caching. That's a 3.3x improvement on its own, independent of language choice. The WASM boundary elimination is 2-4x, but the algorithmic fix is what actually matters for user-perceived latency during streaming. Title undersells the more interesting engineering imo.
More like a misleading clickbait.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#4That blog post design is very nice. I like the 'scrollspy' sidebar which highlights all visible headings.
Claude tells me this is https://www.fumadocs.dev/
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#5"We rewrote this code from language L to language M, and the result is better!" No wonder: it was a chance to rectify everything that was tangled or crooked, avoid every known bad decision, and apply newly-invented better approaches.
So this holds even for L = M. The speedup is not in the language, but in the rewriting and rethinking.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#6I was wondering why I hadn't heard of Open UI doing anything with WASM.
This new company chose a very confusing name that has been used by the Open UI W3C Community Group for over 5 years.
Open UI is the standards group responsible for HTML having popovers, customizable select, invoker commands, and accordions. They're doing great work.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#7What is the purpose of the Rust WASM parser? Didn't understand that easily from the article. Would love a better explanation.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#8"We rewrote this code from language L to language M , and the result is better!" No wonder: it was a chance to rectify everything that was tangled or crooked, avoid every known bad decision, and apply newly-invented better approaches. So this holds even for L = M . The speedup is not in the language, but in the rewriting and rethinking.
Now they just need a third party who's never seen the original to rewrite their TypeScript solution in Rust for even more gains.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#9The real win here isn't TS over Rust, it's the O(N²) -> O(N) streaming fix via statement-level caching. That's a 3.3x improvement on its own, independent of language choice. The WASM boundary elimination is 2-4x, but the algorithmic fix is what actually matters for user-perceived latency during streaming. Title undersells the more interesting engineering imo.
Yeah, though the n^2 is overstating things.
One thing I noticed was that they time each call and then use a median. Sigh. In a browser. :/ With timing attack defenses build into the JS engine.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#10"We rewrote this code from language L to language M , and the result is better!" No wonder: it was a chance to rectify everything that was tangled or crooked, avoid every known bad decision, and apply newly-invented better approaches. So this holds even for L = M . The speedup is not in the language, but in the rewriting and rethinking.
Now they just need a third party who's never seen the original to rewrite their TypeScript solution in Rust for even more gains.
Indeed! But only after a year or so of using it in production, so that the drawbacks would be discovered.