Using WebAssembly to turn Rust crates into fast TypeScript libraries | Hacker News Reader

Using WebAssembly to turn Rust crates into fast TypeScript libraries

rybicki.io

88 pointschriscbr22 comments

Why fast?

In our experience, the cost of boundary-crossing between wasm and js make it slower than js implementation for everything dom-related.

I guess it's best for stuff that isn't dom related

There are a few wasm libraries like finos/perspective and duckdb-wasm that are really useful in the client even though they don't interact with the dom

Thanks for the pointer to duckdb-wasm, didn't know about it!

> These micro benchmarks show that there is also no such thing as free lunch in the browser. We are paying for the increased processing efficiency in WebAssembly with a sightly less efficient evaluation on very small input. Our recommendation is therefore to use DuckDB-Wasm if you need SQL, the features or the raw speed on medium to large data sizes. Stick to existing frameworks if your dataset is very small or if your queries only contain simple scans and filters.

Author here. Yeah, in fairness this post doesn't go into benchmarking (that would be interesting as a follow up). Though I would argue even for libraries that aren't numerically intensive (like the one I used in this blog post), I'd imagine the speeds are probably comparable to the JavaScript runtime if you don't have to boundary cross very often.

In this case, the main thing that was "fast" was that I didn't have to rewrite a nontrivial string formatting library in a new language (I literally couldn't find any other JavaScript libraries that had this kind of error-formatting functionality, so that would have been my only other option). :-)

Cool post! I'm curious how big your wasm file ended up being?

For node, it would be interesting to compare performance, weight, and gotchas of the wasm approach vs. building a shared library with Rust and then pulling it in through node-gyp. Loading wasm is certainly a lot simpler, but multithreading support seems shaky and I imagine there may be some other drawbacks compared compiling into node directly, despite the added complexity.

That's surprising to me, there was a Mozilla post a few years ago saying js to wasm allows 100 million calls per second for the slowest category, which seems speedy enough?

See: https://hacks.mozilla.org/2018/10/calls-between-javascript-a...

I think main issue is when it comes to DOM manipulation, the DOM is generally the bottleneck, not JavaScript. And since the DOM manipulations must be executed by JS anyways, you are often adding overhead by embedding your UI lib into wasm which then needs to message pass with JS to execute the DOM changes anyways.

See: https://krausest.github.io/js-framework-benchmark/current.ht...

To me, the benchmarks you linked show that the fastest WASM web frameworks I know (leptos, dioxus, sycamore) are competitive with, or faster than, the JS frameworks most famously associated with speed, like SolidJS and Svelte; and that they are way faster than React.

That doesn't support your statement here, so I was wondering what takeaway you meant to direct our attention to when providing that link.

The most mature React-like library written in Rust, Yew, is slower than React, as the chart shows. Meanwhile the fastest frameworks are minimal JS / vanilla JS, including the fastest framework, mikado.

Either way it's clear that even a compile time language with no garbage collection can't get faster than the DOM itself allows, which is the crux of my point. In theory a compiled language should run at least twice as fast as JS, but it's not the case in the browser.

Dioxus is also a vDOM based framework (like React). Leptos is a fine-grained-reactivity framework (like SolidJS/Svelte).

They are both _way_ faster than React, and they are both faster than Vue and Svelte by a larger magnitude than SolidJS is faster than either of them.

That is not because Dioxus/leptos have less features than Yew. I'd actually argue they are more feature-full [1].

For icing on the cake: the most "bare-bones" WASM/Rust based entry to the benchmarks, "sledge-hammer", is as fast as the most bare-bones JS entry.

There are valid reasons for not using a Rust frontend framework (over-the-wire size, compilation speed, ecosystem, ..etc), but execution/DOM-manipulation speed is not one of them.

[1] I've used leptos, and tried out Yew, and have read through the docs of all three.

I'm confused, doesn't this show wasm bindgen performing near vanilla js? Admittedly, there's overhead, but fairly minimal. My assumption is that DOM operations are slow because of what they do under the hood, not because of the overhead of calling them.

It does show that, but vanilla JS is 20-30% faster on some of those benchmarks, and the fastest library in the test is a minimal JS lib. Either way, you would expect that a compiled, non-garbage collected, language should be able to achieve 50% or more improvement in speed over JS, but that's not the case in the browser, because the DOM is the bottleneck.

Like I said somewhere else "sledge-hammer" is _just as fast_ as Vanilla JS in those benchmarks (it's one of the "Vanilla Rust"/bare-bones entries to the benchmark).

I'd love to hear more about your experience, because it contradicts what the JS Framework Benchmarks[0] suggests.

Leptos and Dioxus, Rust/WASM frameworks, are competitive with SolidJS, and right out destroy React, when it comes to manipulating the DOM!

So I'd love to hear, if possible, about when was it that you evaluated your WASM based solution, what language and framework you used, etc.

[0] https://krausest.github.io/js-framework-benchmark/2023/table...

We built a prototype using wasm-bindgen where we computed data values (displayed in a large table). Benchmarks were slower than native js.

This was last year though, maybe things got better now, so thanks for the pointers, will do another attempt!

Thanks for providing your data point!

If you're having another go, I'd recommend checking out sledge-hammer[0], a wasm-bindgen alternative that the folks behind Dioxus have been working on. It's a faster, but more limited version. Best of luck!

[0] https://github.com/Demonthos/sledgehammer_bindgen

Thanks!

Indeed, string decoding may have been our bottleneck as explained in [0].

Will definitely have a look.

PS: Evan from https://github.com/Demonthos, if you ever stumble upon this there is typo in the Dioxus link from your bio :)

Nice post! We're compiling Rust to Wasm for a numerical optimizer and got an order of magnitude speedup compared to our previous TypeScript implementation. It was tricky to get all the build pieces working together though.

Our team just uses wasm-bindgen though, and not wasm-pack; curious how much additional value you get from the latter? I could be mistaken but my impression is that wasm-pack uses Webpack; we've generally been trying to use esbuild instead (to make build times faster) but I haven't used wasm-pack beyond running the tutorial so maybe I don't know what I'm missing.

Nice writeup! A small improvement: There is `#[serde(rename_all = "camelCase")]` to avoid typing all properties twice.

Along the same lines, wasm-bindgen can generate the TypeScript types: https://rustwasm.github.io/wasm-bindgen/reference/attributes...

I have a need to create 1 library that can be reused in JVM, NodeJS/TS, Python, Go.

I remember reading something about doing something similar to this but it creates libraries for multiple languages. Have you done something similar before or do you have an idea where to look?

That's really cool! Just saved to home screen for when I need to compile something to wasm

Reply on news.ycombinator.com