That 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/
Interesting, thanks. I need make some good docs soon.
We rewrote our Rust WASM parser in TypeScript and it got faster
11–20 of 239 posts
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#12The 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.
> Title undersells the more interesting engineering imo.
Thanks for cutting through the clickbait. The post is interesting, but I'm so tired of being unnecessarily clickbaited into reading articles.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#13That 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/
Interesting, thanks. I need make some good docs soon.
Good documentation is always worth the effort. Markdown explaining your products is gold these days with LLMs.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#14The 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.
same for uv but no one takes that message. They just think "rust rulez!" and ignore that all of uv's benefits are algo, not lang.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#15By the way, I did a deeper dive on the problem of serializing objects across the Rust/JS boundary, noticed the approach used by serde wasn’t great for performance, and explored improving it here: https://neugierig.org/software/blog/2024/04/rust-wasm-to-js....
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#16"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.
Truth. You can see improvement, even rewriting code in the same language.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#17They should rewrite it in rust again to get another 3x performance increase /s
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#18The 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.
same for uv but no one takes that message. They just think "rust rulez!" and ignore that all of uv's benefits are algo, not lang.
Some architectures are made easier by the choice of implementation language.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#19Am I mistaken or isn’t TypeScript just Golang under the hood these days?
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#20What is the purpose of the Rust WASM parser? Didn't understand that easily from the article. Would love a better explanation.
They use a bespoke language to define LLM-generated UI components. I think that this is supposed to prevent exfiltration if the LLM is prompt-injected. In any case, the parser compiles chunks streaming from the LLM to build a live UI. The WASM parser restarted from the beginning upon each chunk received. Fixing this algorithm to work more incrementally (while porting from Rust to TypeScript) improved performance a lot.