Discussion

Rewriting our Rust WASM Parser in TypeScript

spankalee: I 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.https://open-ui.org/Open UI is the standards group responsible for HTML having popovers, customizable select, invoker commands, and accordions. They're doing great work.

nine_k: "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.

MiddleEndian: Now they just need a third party who's never seen the original to rewrite their TypeScript solution in Rust for even more gains.

nine_k: Indeed! But only after a year or so of using it in production, so that the drawbacks would be discovered.

blundergoat: The 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.

sroussey: 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.

baranul: Truth. You can see improvement, even rewriting code in the same language.

evmar: By 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....

socalgal2: 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.

estebank: Some architectures are made easier by the choice of implementation language.

SCLeo: They should rewrite it in rust again to get another 3x performance increase /s

slowhadoken: Am I mistaken or isn’t TypeScript just Golang under the hood these days?

iainmerrick: Hmm, there's an in-progress rewrite of the TypeScript compiler in Go; is that what you mean?

szmarczak: > Attempted Fix: Skip the JSON Round-Trip > We integrated serde-wasm-bindgenSo you're reinventing JSON but binary? V8 JSON nowadays is highly optimized [1] and can process gigabytes per second [2], I doubt it is a bottleneck here.[1] https://v8.dev/blog/json-stringify [2] https://github.com/simdjson/simdjson

neuropacabra: This is very unusual statement :-D

joaohaas: God I hate AI writing.That final summary benchmark means nothing. It mentions 'baseline' value for the 'Full-stream total' for the rust implementation, and then says the `serde-wasm-bindgen` is '+9-29% slower', but it never gives us the baseline value, because clearly the only benchmark it did against the Rust codebase was the per-call one.Then it mentions: "End result: 2.2-4.6x faster per call and 2.6-3.3x lower total streaming cost."But the "2.6-3.3x" is by their own definition a comparison against the naive TS implementation.I really think the guy just prompted claude to "get this shit fast and then publish a blog post".

fn-mote: For those of us not in the know, what are we expecting the results of the defenses to be here?

azakai: You're generally right - rewrites let you improve the code - but they do have an actual reason the new language was better: avoiding copies on the boundary.They say they measured that cost, and it was most of the runtime in the old version (though they don't give exact numbers). That cost does not exist at all in the new version, simply because of the language.

rowanG077: That's a pretty big claim. I don't doubt that a lot of uv's benefits are algo. But everything? Considering that running non IO-bound native code should be an order of magnitude faster than python.

ivanjermakov: Good software is usually written on 2nd+ try.

nallana: Why not a shared buffer? Serializing into JSON on this hot path should be entirely avoidable

azakai: O(N²) -> O(N) was 3.3x faster, but before that, eliminating the boundary (replacing wasm with JS) led to speedups of 2.2x, 4.6x, 3.0x (see one table back).It looks like neither is the "real win". both the language and the algorithm made a big difference, as you can see in the first column in the last table - going to wasm was a big speedup, and improving the algorithm on top of that was another big speedup.

nulltrace: Yeah the algorithmic fix is doing most of the work here. But call that parser hundreds of times on tiny streaming chunks and the WASM boundary cost per call adds up fast. Same thing would happen with C++ compiled to WASM.