Leptos creator Greg Johnston examines Rust/WebAssembly frontend frameworks against JavaScript frameworks using the JS framework benchmark. He argues that WASM is no longer too slow for DOM-heavy rendering.
Why Hacker News points people here: Cited as evidence that DOM access is not the bottleneck for WebAssembly, and as an explanation of signals-based updates versus virtual DOM.
“did a pretty good video about this a few weeks ago[0]”HN comment, 2023
“did a pretty good video about this a few weeks ago[0]”
Explains DOM binding costs eat WASM compute gains.
Full comment
Greg Johnston, author of the Leptos framework, did a pretty good video about this a few weeks ago[0]. The TLDR is (of course): it depends. WASM has no native access to the DOM, so all DOM manipulations from wasm-land have to go through JS bindings with all the (de)serialisation costs that go with crossing the language boundary. That eats up a lot of whatever performance gains you'd see from rust-on-wasm for pure compute. 0. this video
RecommendstheironhammerJul 2023
“This video might be helpful.”
Helps understand signals-based DOM updates versus virtual DOM.
Full comment
this video This video might be helpful. Leptos uses Signals, borrowing ideas from SolidJS to update the DOM. There's no VirtualDOM like React. Svelte also doesn't use a VDOM. When there's a state change React has to rerender the entire VDOM tree and the diff it with the real DOM, whereas using the Signals model those frameworks make the change directly in the real DOM. I'm not sure how Svelte manipulates the DOM exactly but I it's similar to how it's done with Frameworks that use Signals such as Leptos and SolidJS. I would say Developer velocity is key if you're a developer. Svelte is a big winner here as it's mental model is easier to understand than React's.
Cites itrapnieAug 2023
“Greg Johnston, creator of Leptos, has made a video with performance comparisons”
Performance comparisons from Leptos creator.
Full comment
> if anyone tells you they need to use WebAssembly to make the UI snappy I'd advise you interrogate that assertion thoroughly. Get prepared to be blown away by Makepad [0]. I have no affiliation with them, but just watched their most recent conference presentation [1]. The slides were made with Makepad itself and included, embedded, a full-blown IDE, a synthesizer app, a Mandelbrot to zoom in endlessly, and more. All running at 120fps. The presentation is for the most part live-coding with this setup. What they want to do is bring coders and designers closer together, and while some code is in Rust they developed a DSL for the GUI parts that is close to how Figma works. These GUI's can run anywhere. And I couldn't help thinking "Why would people have complicated stacks to create Web 2.0 apps for the Google Web, when they have this?", in other words an opportunity to break out of the browser straitjacket. Btw. WebAssembly/WebGL isn't the only way in which Makepad is available. And while running well in the browser for a time, there were issues to be solved here (addressed in the presentation). And tbh this isn't a real answer to your assertion. Greg Johnston, creator of Leptos, has made a video with performance comparisons [2]. [0] link [1] link [2] this video
Cites itazemetreAug 2023
“The benchmarks being displayed have leptos beating react in nearly every category.”
Benchmarks show Leptos beating React in nearly every category.
Full comment
Have you seen the video posted in the parent, by the creator of leptos (a rust webassembly framework)? this video The benchmarks being displayed have leptos beating react in nearly every category.
Cites itnanaianJan 2024
“It's performant, too”
Evidence that Wasm DOM access is performant.
Full comment
Wasm threads via SharedArrayBuffer have been a thing for like 5 years. In Rust you can use wasm-bindgen-rayon, for instance. DOM access is and has always been easily achieved through imports. It's performant, too: this video
Cites itjbjohnsOct 2024
“makes a pretty good argument [1] that the bottleneck for WASM isn't really the DOM”
Argues the DOM is not the Wasm bottleneck.
Full comment
The founder of Leptos makes a pretty good argument [1] that the bottleneck for WASM isn't really the DOM and that they are already faster than some popular JS frameworks even with the current constraints. [1] this video
Cites ittcfhgjFeb 2026
“A demonstration of that by the creator of Leptos”
Demonstrates JS layer overhead isn't prohibitive.
Full comment
the JS layer is slow, indeed, but it shouldn't be that much slower that it meaningfully impacts frontend apps A demonstration of that by the creator of Leptos: this video
Cites ittcfhgjMar 2026
“Source: Analysis of the creator of Leptos (a web framework based on WASM)”
Analysis showing WASM frameworks compete with JS in DOM-heavy work.
Full comment
> no DOM access meant the only viable use cases were compute-heavy workloads like codecs and crypto, no, it didn't mean that, because the overhead is not a deal breaker: 1) you don't have to do the glue code (libs can do it for you) 2) there's overhead due to glue, but the overhead is so small that WASM web frameworks easily can compete with fast JS frameworks in DOM heavy scenarios. Source: Analysis of the creator of Leptos (a web framework based on WASM): this video
