Hacker News

We rewrote our Rust WASM Parser in TypeScript – and it got 3x Faster

• 54 Comments
• Something not unlike this happened to me when moving some batch processing code from C++ to Python 1.4 (this was 1997). The batch started finishing about 10x faster. We refused to believe it at first and started looking to make sure the work was actually being done. It was.
  The port had been done in a weekend just to see if we could use Python in production. The C++ code had taken a few months to write. The port was pretty direct, function for function. It was even line for line where language and library differences didn't offer an easier way.
  A couple of us worked together for a day to find the reason for the speedup. Just looking at the code didn't give us any clues, so we started profiling both versions. We found out that the port had accidentally fixed a previously unknown bug in some code that built and compared cache keys. After identifying the small misbehaving function, we had to study the C++ code pretty hard to even understand what the problem was. I don't remember the exact nature of the bug, but I do remember thinking that particular type of bug would be hard to express in Python, and that's exactly why it was accidentally fixed.
  We immediately started moving the rest of our back end to Python. Most things were slower, but not by much because most of our back end was i/o bound. We soon found out that we could make algorithmic improvements so much more quickly, so a lot of the slowest things got a lot faster than they had ever been. And, most importantly, we (the software developers) got quite a bit faster.

  By rented_mule 2 hours ago

• > After identifying the small misbehaving function, we had to study the C++ code pretty hard to even understand what the problem was. I don't remember the exact nature of the bug, but I do remember thinking that particular type of bug would be hard to express in Python, and that's exactly why it was accidentally fixed.
  Pure speculation, but I would guess this has something to do with a copy constructor getting invoked in a place you wouldn't guess, that ends up in a critical path.

  By asveikau 23 minutes ago

• good ol' shallow-vs-deep copy

  By NooneAtAll3 19 minutes ago

• This is the argument Grace Hopper made in the 1950s when she was pushing for high-level languages.
  Her colleagues insisted that compilers could never match hand-written assembly.
  She argued that programmer productivity mattered more, that humans working in a language closer to their thinking would write better programs faster, and the net result would be better software. Seventy years later, the same pattern keeps playing out.

  By DaleBiagio an hour ago

• Fun story! Performance is often highly unintuitive, and even counterintuitive (e.g. going from C++ to Python). Very much an art as well as a science.
  Crazy how many stories like this I’ve heard of how doing performance work helped people uncover bugs and/or hidden assumptions about their systems.

  By asa400 an hour ago

• Agreed — the headline buries the lede. Algorithmic complexity improvements compound across all future inputs regardless of implementation language, while the WASM boundary win is more of a one-time gain. Worth noting that the statement-level caching insight generalises well: many parser-adjacent hot paths suffer the same O(N²) trap when doing repeated prefix/suffix matching without memoisation.

  By envguard an hour ago

• 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.

  By blundergoat 4 hours ago

• 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.

  By azakai 2 hours ago

• 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.

  By nulltrace 2 hours ago

• 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.

  By socalgal2 3 hours ago

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

  By estebank 2 hours ago

• In my experience Rust typically makes it a little bit harder to write the most efficient algo actually.

  By crubier an hour ago

• 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.

  By rowanG077 2 hours ago

• Its a pretty well-supported claim. uv skips doing a number of things that generate file I/O. File I/O is far more costly than the difference in raw computation. pip can't drop those for compatibility reasons.
  https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html

  By jeremyjh an hour ago

• I don't think the article you linked supports the claim that none of UV performance improvements are related to using rust over python at all. In fact it directly states the exact opposite. They have an entire section dedicated to why using Rust has direct performance advantages for UV.

  By rowanG077 34 minutes ago

• More than one, I'd think.

  By thfuran an hour ago

• > 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.

  By Aurornis 3 hours ago

• 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.

  By sroussey 3 hours ago

• For those of us not in the know, what are we expecting the results of the defenses to be here?

  By fn-mote 2 hours ago

• More like a misleading clickbait.

  By shmerl 3 hours ago

• "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.

  By nine_k 3 hours ago

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

  By MiddleEndian 3 hours ago

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

  By nine_k 3 hours ago

• 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.

  By azakai 2 hours ago

• I think that they were honest about that too a degree, they pointed out that one source of the speed up was caused by the python fixing a big they hadn't noticed on the C++

  By awesome_dude 9 minutes ago

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

  By baranul 3 hours ago

• 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....

  By evmar 3 hours ago

• Did you try something like msgpack or bebop?

  By slopinthebag an hour ago

• 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.

  By spankalee 3 hours ago

• > The openui-lang parser converts a custom DSL emitted by an LLM into a React component tree.
  > converts internal AST into the public OutputNode format consumed by the React renderer
  Why not just have the LLM emit the JSON for OutputNode ? Why is a custom "language" and parser needed at all? And yes, there is a cost for marshaling data, so you should avoid doing it where possible, and do it in large chunks when its not possible to avoid. This is not an unknown phenomenon.

  By jeremyjh an hour ago

• Not directly related to the post but what does OpenUI do? I'm finding it interesting but hard to understand. Is it an intermediate layer that makes LLMs generate better UI?

  By vmsp an hour ago

• I dream of the day in which there is no need to pass by JS and Wasm can do all the job by itself. Meanwhile, we are stuck.

  By kennykartman an hour ago

• It would be great if people stopped dismissing the problem that WASM not being a first-class runtime for the web causes.

  By marcosdumay an hour ago

• The WASM story is interesting from a security angle too. WASM modules inheriting the host's memory model means any parsing bugs that trigger buffer overreads in the Rust code could surface in ways that are harder to audit at the JS boundary. Moving to native TS at least keeps the attack surface in one runtime, even if the theoretical memory safety guarantees go down.

  By envguard an hour ago

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

  By nallana 2 hours ago

• I think a shared array just avoids the copy, not the serialization which is the main problem as they showed with serde-wasm-bindgen test

  By mavdol04 an hour ago

• Good software is usually written on 2nd+ try.

  By ivanjermakov 2 hours ago

• This article is obviously AI generated and besides being jarring to read, it makes me really doubt its validity. You can get substantially faster parsing versus `JSON.parse()` by parsing structured binary data, and it's also faster to pass a byte array compared to a JSON string from wasm to the browser. My guess is not only this article was AI generated, but also their benchmarks, and perhaps the implementation as well.

  By slopinthebag an hour ago

• It's vibe code all the way down!

  By StilesCrisis an hour ago

• 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".

  By joaohaas 2 hours ago

• 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/

  By dmix 3 hours ago

• Interesting, thanks. I need make some good docs soon.

  By sroussey 3 hours ago

• Good documentation is always worth the effort. Markdown explaining your products is gold these days with LLMs.

  By dmix 3 hours ago

• Rewrite bias. Yoy want to also rewrite the Rust one in Rust for comparison.

  By nssnsjsjsjs 2 hours ago

• It would be surprising if rewriting in Rust could change the WASM boundary tax that the article identified as the actual problem.

  By jeremyjh an hour ago

• What is the purpose of the Rust WASM parser? Didn't understand that easily from the article. Would love a better explanation.

  By caderosche 3 hours ago

• 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.

  By joshuanapoli 2 hours ago

• This is very unusual statement :-D

  By neuropacabra 2 hours ago

• > Attempted Fix: Skip the JSON Round-Trip > We integrated serde-wasm-bindgen
  So 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

  By szmarczak 2 hours ago

• No, serde-wasm-bindgen implements the serde Serializer interface by calling into JS to directly construct the JS objects on the JS heap without an intermediate serialization/deserialization. You pay the cost of one or more FFI calls for every object though.
  https://docs.rs/serde-wasm-bindgen/

  By kam an hour ago

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

  By slowhadoken 2 hours ago

• There is too much wrong here to call it a mistake.

  By jeremyjh an hour ago

• Hmm, there's an in-progress rewrite of the TypeScript compiler in Go; is that what you mean?
  I don't think that's actually out yet, and more importantly, it doesn't change anything at runtime -- your code still runs in a JS engine (V8, JSC etc).

  By iainmerrick 2 hours ago

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

  By SCLeo 2 hours ago