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