Live data from Hacker News

We rewrote our Rust WASM parser in TypeScript and it got faster

openui.com

41–50 of 239 posts

Re: We rewrote our Rust WASM parser in TypeScript and it got faster

#41
> 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.

Re: We rewrote our Rust WASM parser in TypeScript and it got faster

#42
post #15

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

Did you try something like msgpack or bebop?

Re: We rewrote our Rust WASM parser in TypeScript and it got faster

#43

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 we…

It's vibe code all the way down!

Re: We rewrote our Rust WASM parser in TypeScript and it got faster

#44

Earlier quoted context omitted.

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.

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

Re: We rewrote our Rust WASM parser in TypeScript and it got faster

#45
post #25

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

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

Re: We rewrote our Rust WASM parser in TypeScript and it got faster

#47

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…

[flagged]

Re: We rewrote our Rust WASM parser in TypeScript and it got faster

#48

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…

[dead]

Re: We rewrote our Rust WASM parser in TypeScript and it got faster

#49
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.

Re: We rewrote our Rust WASM parser in TypeScript and it got faster

#50

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…

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.

Post reply on HN