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

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.

Yeah if you're serializing and deserializing data across the JS-WASM boundary (or actually between web workers in general whether they're WASM or not) the data marshaling costs can add up. There is a way of sharing memory across the boundary though without any marshaling: TypedArrays and SharedArrayBuffers. TypedArrays let you transfer ownership of the underlying memory from one worker (or the main thread) to another without any copying. SharedArrayBuffers allow multiple workers to read and write to the same contiguous chunk of memory. The downside is that you lose all the niceties of any JavaScript types and you're basically stuck working with raw bytes.<p>You still do get some latency from the event loop, because postMessage gets queued as a MacroTask, which is probably on the order of 10μs. But this is the price you have to pay if you want to run some code in a non-blocking way.

“We saw huge speed-ups when changing technology.”<p>Looks inside<p>“The old implementation had some really inappropriate choices.”<p>Every time.

"We rewrote this code from language <i>L</i> to language <i>M</i>, 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.<p>So this holds even for <i>L = M</i>. The speedup is not in the language, but in the rewriting and rethinking.

This has been known by Node.js developers for a while with many C++ core and NPM modules being rewritten in JavaScript to improve performance.

This is why, when a programming language already has tooling for compilers, being it ahead of time, or dynamic, it pays off to first go around validating algorithms and data structures before a full rewrite.<p>Additionally even after those options are exhausted, only a key parts might need a rewrite, not the whole thing.<p>However, I wonder how many care about actually learning about algorithms, data structures and mechanical sympathy in the age of Electron apps.<p>It feels quite often that a rewrite is chosen, because knowing how to actually apply those skills is the CS stuff many think isn't worthwhile learning about.

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: <a href="https://neugierig.org/software/blog/2024/04/rust-wasm-to-js.html" rel="nofollow">https://neugierig.org/software/blog/2024/04/rust-wasm-to-js....</a>

I was wondering why I hadn't heard of Open UI doing anything with WASM.<p>This new company chose a very confusing name that has been used by the Open UI W3C Community Group for over 5 years.<p><a href="https://open-ui.org/" rel="nofollow">https://open-ui.org/</a><p>Open UI is the standards group responsible for HTML having popovers, customizable select, invoker commands, and accordions. They're doing great work.

In ye olden days of WASM just added to the browser, the difference between native JS and boost::spirit in WASM was x200.<p>In their worst case it was just x5. We clearly have some progress here.

[deleted]

JS and WASM share the main arraybuffer. It's just very not-javascript-like to try to use an arraybuffer heap, because then you don't have strings or objects, just index,size pairs into that arraybuffer.<p>Anyway, Javascript is no stranger to breaking changes. Compare Chromium 47 to today. Just add actual integers as another breaking change, then WASM becomes almost unnecessary.

Its also worth underlining that it's not just "The parsing computation is fast enough that V8's JIT eliminates any Rust advantage", but specifically that this kind of straight-forward well-defined data structures and mutation, without any strange eval paths or global access is going to be JITed to near native speed relatively easily.

God I hate AI writing.<p>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.<p>Then it mentions: "End result: 2.2-4.6x faster per call and 2.6-3.3x lower total streaming cost."<p>But the "2.6-3.3x" is by their own definition a comparison against the naive TS implementation.<p>I really think the guy just prompted claude to "get this shit fast and then publish a blog post".

Is this an outlier or has Rust started to be part of the establishment and being 'old' so that people want to share their "moving away from Rust" stories?<p>I didn't mind reading articles that are not about how Rust is great in theory (and maybe practice).

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?

[deleted]

> The openui-lang parser converts a custom DSL emitted by an LLM into a React component tree.<p>> converts internal AST into the public OutputNode format consumed by the React renderer<p>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.

I’m more of a dabbler dev/script guy than a dev but Every. single. thing I ever write in javascript ends up being incredibly fast. It forces me to think in callbacks and events and promises. Python and C (or async!) seem easy and sorta lazy in comparison.

This somehow reminds me of the days when the fastest way to deep copy an object in javascript was to round trip through toString. I thought that was gross then, and I think this is gross now

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.

I hope we can still get to a point where wasm modules can directly access the web platform APIs and get JS out of the picture entirely. After all, those APIs themselves are implemented in C++ (and maybe some Rust now).

I heard a lot of similar stories in the past when I started using Python 20+ years ago. A number of people claimed their solutions got faster when develop in Python, mainly because Python make it easier to quickly pivot to experiment with various alternative methods, hence finally yield at more efficient outcome at the end.

I almost can't believe this swc for example is 80x faster then babeljs.

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.

Good software is usually written on 2nd+ try.

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

So this is an issue with WASM/JS interop, not with Rust per se?

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

That blog post design is very nice. I like the 'scrollspy' sidebar which highlights all visible headings.<p>Claude tells me this is <a href="https://www.fumadocs.dev/" rel="nofollow">https://www.fumadocs.dev/</a>

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.

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

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

So ...<p>Rust.<p>WASM.<p>TypeScript.<p>I am slowly beginning to understand why WASM did not really succeed.

> Attempted Fix: Skip the JSON Round-Trip > We integrated serde-wasm-bindgen<p>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.<p>[1] <a href="https://v8.dev/blog/json-stringify" rel="nofollow">https://v8.dev/blog/json-stringify</a> [2] <a href="https://github.com/simdjson/simdjson" rel="nofollow">https://github.com/simdjson/simdjson</a>

I tried a similar experiment recently w/ FFT transform for wav files in the browser and javascript was faster than wasm. It was mostly vibe coded Rust to wasm but FFT is a well-known algorithm so I don't think there were any low hanging performance improvements left to pick.

This is very unusual statement :-D

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

[dead]

[dead]

[dead]

[dead]

[dead]

[dead]

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

[dead]