Hacker News Reader

Comment by sljsdljfslkj | Hacker News Reader

> but its the Javascript that causes it to crawl

If it's updating a web view then it needs to go through javascript. The fastest rust wasm frameworks are not faster than javascript by any meaningful amount.

View on HN

This is actually wrong in this context. Rust is running natively here (so no WebAssembly), directly manipulating the DOM of the web view without having to go through JavaScript glue code.

How is Rust manipulating the DOM?

It uses IPC to give the WebView patches of what to do. There is a wee bit of JS there that parses the IPC and applies the patch to the DOM.

Here's the code: https://github.com/DioxusLabs/dioxus/tree/master/packages/in...

So is my parent wrong and my grandparent correct? Because that is what I thought as well. DOM mutations are still happening via JS, so while the business logic might be in Rust, the mutations are still bounded by the speed of JS.

DOM mutations still happen in JS, they are just send from native-rust code. It is exactly like a liveview with a local server + webview wrapper

This explains how Dioxus also has a LiveView mode - that sounds exactly how LiveView works.

I think this would be very situational even in the case of WASM. Without needing a garbage collector and using only a JS buffer for message handling and DOM updates, for a long running application, there might be performance gains that would be hard to directly measure. With simple examples, the JS will generally win handedly. But for more complex apps that use more / increasing memory and perform involved state manipulation, I’m willing to bet you’d see the favor slip.

This manifests as a snappier experience with less / no GC pauses and a clearer dev experience with a better separation between domains. Rust is just a better language to work with, so it has a certain future-proof quality to it that would pay dividends long term compared to JS in any case.

Reply on news.ycombinator.com