3 ms·

> 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 f

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

dindresto 4y ago
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.
- fastball 4y ago
  How is Rust manipulating the DOM?
  - terhechte 4y ago
    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/interpreter https://github.com/DioxusLabs/dioxus/tree/master/packages/in...
    - lucasyvas 4y ago
      This explains how Dioxus also has a LiveView mode - that sounds exactly how LiveView works.
    - fastball 4y ago
      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.
      - demonthos 4y ago
        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
- deleted 4y ago
  [deleted]
survirtual 4y ago
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.

dindresto 4y ago

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.

fastball 4y ago
How is Rust manipulating the DOM?
- terhechte 4y ago
  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/interpreter https://github.com/DioxusLabs/dioxus/tree/master/packages/in...
  - lucasyvas 4y ago
    This explains how Dioxus also has a LiveView mode - that sounds exactly how LiveView works.
  - fastball 4y ago
    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.
    - demonthos 4y ago
      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
deleted 4y ago
[deleted]

survirtual 4y ago

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.