Re:We rewrote our Rust WASM Parser in TypeScript – and it go...
by chvish on Saturday March 21, 2026 @01:12AM
(#47464163)
This. It’s so annoying to read these types of blogs now where the writer clearly didn’t put the effort to understand things fully or atleast review the blog their LLM wrote. Who is this useful for?
Re:We rewrote our Rust WASM Parser in TypeScript – and it go...
by JimDabell on Saturday March 21, 2026 @01:29AM
(#47464239)
The article as a whole makes no sense. They are generating UI with an LLM. How fast the UI appears to the user is going to be completely dictated by the speed of the LLM, not the speed of the serialisation.
Re:We rewrote our Rust WASM Parser in TypeScript – and it go...
by rabisg on Saturday March 21, 2026 @03:25AM
(#47464787)
as an author of the blog - ouch
did a little bit more than prompt claude but a lot of claude prompting was definitely involved
I understand your frustration with AI writing though. We are a small team and given our roadmap it was either use LLMs to help collate all the internal benchmark results file into a blog or never write it so we chose the former. This was a genuinely surprising and counterintuitive result for us, which is why we wanted to share it. Happy to clarify any of the numbers if helpful.
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".