7 ms·

Just a Brief note about Tauri VS Electron. I've always been a opponent of Electron Apps. Even now, my Slack regularly pauses for seconds I suppose because the G

Just a Brief note about Tauri VS Electron. I've always been a opponent of Electron Apps. Even now, my Slack regularly pauses for seconds I suppose because the Garbage Collector has to do its thing. Lately, however, I've worked on a Mastodon Client written in Dioxus (https://terhech.de/ebou/ https://terhech.de/ebou/). Dioxus runs native Rust code and sends Dom Updates to a Tauri Webview. The difference in Ram and Performance is staggering. Much more lightweight because it uses the System Webview, and much faster because it's not Javascript. I've come to the conclusion that Electron itself is probably fast enough, but its the Javascript that causes it to crawl. (Obviously, my tiny app doesn't compare to Slack, but I've also done some simple-enough Electron Experiments). And it makes sense: WebKit has seen tremendous amounts of investments to make it as fast as possible. CSS can do GPU based transforms, everything is heavily optimised. I'd venture that WebView rendering is just as fast as native (in the general case). What makes Electron slow is Javascript.

sljsdljfslkj 4y ago
> 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
I noticed the Dioxus page about desktop support with Tauri mentioning that this won't allow access to any Web APIs, like WebGL or WebGPU. This made me wonder: Is it possible to embed a native view inside of the webview rendered by Tauri? To be precise, could we make use of the native wgpu crate to embed a 3D rendered scene inside Tauri?
- dindresto 4y ago
  Looks like someone attempted this last year, without any success unfortunately: https://github.com/dceddia/wgpu-tauri-experiment https://github.com/dceddia/wgpu-tauri-experiment
- terhechte 4y ago
  Yeah that works, because you get access to the native window. I'm adding native macOS elements to the Ebou window, for example. I'm also adding native window effects. You could reasonably easy add a wgpu native view I guess. What's a bit more difficult would be to have it position correctly (because you'd need to know the locations of the html elements, and you can only query them via the `eval` js routine, but that would also work).
simion314 4y ago
Did you benchmark? JavaScript is fat enough, from my experience DOM manipulations nd repaints are the issue. My suggestion in general not specifically for you is to Profile the slow part of the app and find the problem.
flohofwoe 4y ago
From my experience with asm.js vs wasm vs native code, I bet it's not Javascript being slow, but specifically Slack. Properly written Javascript running on V8 can be in the same ballpark as WASM and native code as long as you don't torture the GC. Native code may give you more "optimization headroom" of course, especially with non-standard compiler extensions, but it's not "automatically" drastically faster than JS or WASM (without putting manual effort into optimization, but many of those optimizations would also benefit JS or WASM).
- MrJohz 4y ago
  A good example here is looking at some of the framework benchmarks for frontend frameworks (e.g. https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...) I find useful comparison points are usually React, Preact, and SolidJS: React is fairly slow, but it can do pretty much everything, Preact is React with a lot of parts ripped out to provide a more efficient, slimline version, and SolidJS completely changes the rendering model and is probably the upper limit on how efficient a front-end framework written in Javascript can be. It's very interesting to compare those with Rust-based frameworks. The big noticeable difference is that all the Rust-based frameworks require significantly more memory, even than React, and ship a lot more total code. However, in terms of performance, they are ringed by Javascript frameworks: SolidJS is by far the fastest framework (although Dioxus is catching up in most areas), and React is by far the slowest. Obviously a lot of this is to do with how they interact with the DOM. Javascript gets that for free, but Rust and other WASM-based frameworks have to go through a process boundary in order to read or write DOM values. When direct DOM access eventually comes, I suspect we'll see some pretty big changes in these results. But for now, it's pretty clear that the most important thing for optimisation purposes is your application's architecture, rather than the choice of language.
  - deleted 4y ago
    [deleted]
  - nicoburns 4y ago
    I think these results point to something frontend developers have known for years: JS is rarely the bottleneck. It's DOM/layout/paint that tends to be slow when something is slow. And that layer isn't changed by using Rust.
pjmlp 4y ago
Here is the trick for Electron junk, when they have the option to do so, use the Web app.
sebastianconcpt 4y ago
The backend is Rust, all the frontend and all whatever UI put on top of that WebView is JavaScript alright. I do endorse moving from Electron to Tauri tho. I did it for one of my pet projects and I couldn't be happier. Feels brilliant.
- terhechte 4y ago
  Not with Dioxus. Everything is Rust there. It uses IPC to communicate with the webview and tell it what to draw. It is actually a very smart design. In addition (because WebView is just a Renderer), you can replace WebView with Terminal UI or Native UI
nwienert 4y ago
While JS won’t match Rust for speed, you are likely experiencing WebKits general large performance advantage over Blink as well. A JS dev who knows generally how to write performant apps can produce some very close to native feeling experiences in WebKit, it simply feels that fast. Rust meanwhile is a terrible language for UI work. Just like you wouldn’t use assembly for game programming today, or even why you wouldn’t use JS for sensitive systems programming, you don’t use a static compiled, verbose, picky, slow compiling language for a domain that simply demands you have a totally different set of trade offs. The nature of UI is this: you’re going to iterate a ton, change a ton, you need to be creative and willing to try and throw away experiments as fast as possible, you need the fastest possible feedback cycle between save and hot reload. Your problem space will never be as clear as systems programming. Because the output is visual that time diff between “hmm does this work” and “ok yes/no” needs to be as quick as possible, and you absolutely need to be able to go from idea to output in as quick a time as possible. This is hugely a function of verbosity, elegance of the libraries and hot reload - JS absolutely crushes Rust along these axis. Meanwhile memory safety isn’t a big concern. But not just that, dynamic languages give you dev tools where you can inspect, edit and test changes and code at runtime and that’s the single biggest productivity boost you’ll find as a frontend dev. These are lessons learned over 20 years of developing for every UI platform under the sun. The modern web stack is simply going to get you to production with a far higher quality of UI in way, way less time. I could go on for a lot longer about this topic but suffice it to say: JS is an absolutely incredible language for fronted. It’s set of trade offs match the domain beautifully. I wish it was faster, but WebKit at this point is so much faster and less energy intensive than Blink that I’m extremely happy with app performance in it.
- tayistay 4y ago
  I think the jury is still out on whether rust is good or bad for UI. Once rust UI libraries are more mature we'll get a sense of it. There are some advantages of static typing, even for UI (see SwiftUI for example). I'll grant the pickiness of rust can be a challenge. Anyway give us some time to work on stuff. Here's my effort: https://github.com/audulus/rui https://github.com/audulus/rui
  - 4y ago
Klonoar 4y ago
>What makes Electron slow is Javascript. This has been said as far back as when Slack engineers explained why they migrated away from system webviews to Electron here on HN.

sljsdljfslkj 4y ago

> 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

I noticed the Dioxus page about desktop support with Tauri mentioning that this won't allow access to any Web APIs, like WebGL or WebGPU. This made me wonder: Is it possible to embed a native view inside of the webview rendered by Tauri? To be precise, could we make use of the native wgpu crate to embed a 3D rendered scene inside Tauri?

dindresto 4y ago
Looks like someone attempted this last year, without any success unfortunately: https://github.com/dceddia/wgpu-tauri-experiment https://github.com/dceddia/wgpu-tauri-experiment
terhechte 4y ago
Yeah that works, because you get access to the native window. I'm adding native macOS elements to the Ebou window, for example. I'm also adding native window effects. You could reasonably easy add a wgpu native view I guess. What's a bit more difficult would be to have it position correctly (because you'd need to know the locations of the html elements, and you can only query them via the `eval` js routine, but that would also work).

simion314 4y ago

Did you benchmark? JavaScript is fat enough, from my experience DOM manipulations nd repaints are the issue. My suggestion in general not specifically for you is to Profile the slow part of the app and find the problem.

flohofwoe 4y ago

From my experience with asm.js vs wasm vs native code, I bet it's not Javascript being slow, but specifically Slack. Properly written Javascript running on V8 can be in the same ballpark as WASM and native code as long as you don't torture the GC. Native code may give you more "optimization headroom" of course, especially with non-standard compiler extensions, but it's not "automatically" drastically faster than JS or WASM (without putting manual effort into optimization, but many of those optimizations would also benefit JS or WASM).

MrJohz 4y ago
A good example here is looking at some of the framework benchmarks for frontend frameworks (e.g. https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...) I find useful comparison points are usually React, Preact, and SolidJS: React is fairly slow, but it can do pretty much everything, Preact is React with a lot of parts ripped out to provide a more efficient, slimline version, and SolidJS completely changes the rendering model and is probably the upper limit on how efficient a front-end framework written in Javascript can be. It's very interesting to compare those with Rust-based frameworks. The big noticeable difference is that all the Rust-based frameworks require significantly more memory, even than React, and ship a lot more total code. However, in terms of performance, they are ringed by Javascript frameworks: SolidJS is by far the fastest framework (although Dioxus is catching up in most areas), and React is by far the slowest. Obviously a lot of this is to do with how they interact with the DOM. Javascript gets that for free, but Rust and other WASM-based frameworks have to go through a process boundary in order to read or write DOM values. When direct DOM access eventually comes, I suspect we'll see some pretty big changes in these results. But for now, it's pretty clear that the most important thing for optimisation purposes is your application's architecture, rather than the choice of language.
- deleted 4y ago
  [deleted]
- nicoburns 4y ago
  I think these results point to something frontend developers have known for years: JS is rarely the bottleneck. It's DOM/layout/paint that tends to be slow when something is slow. And that layer isn't changed by using Rust.

pjmlp 4y ago

Here is the trick for Electron junk, when they have the option to do so, use the Web app.

sebastianconcpt 4y ago

The backend is Rust, all the frontend and all whatever UI put on top of that WebView is JavaScript alright. I do endorse moving from Electron to Tauri tho. I did it for one of my pet projects and I couldn't be happier. Feels brilliant.

terhechte 4y ago
Not with Dioxus. Everything is Rust there. It uses IPC to communicate with the webview and tell it what to draw. It is actually a very smart design. In addition (because WebView is just a Renderer), you can replace WebView with Terminal UI or Native UI

nwienert 4y ago

While JS won’t match Rust for speed, you are likely experiencing WebKits general large performance advantage over Blink as well. A JS dev who knows generally how to write performant apps can produce some very close to native feeling experiences in WebKit, it simply feels that fast. Rust meanwhile is a terrible language for UI work. Just like you wouldn’t use assembly for game programming today, or even why you wouldn’t use JS for sensitive systems programming, you don’t use a static compiled, verbose, picky, slow compiling language for a domain that simply demands you have a totally different set of trade offs. The nature of UI is this: you’re going to iterate a ton, change a ton, you need to be creative and willing to try and throw away experiments as fast as possible, you need the fastest possible feedback cycle between save and hot reload. Your problem space will never be as clear as systems programming. Because the output is visual that time diff between “hmm does this work” and “ok yes/no” needs to be as quick as possible, and you absolutely need to be able to go from idea to output in as quick a time as possible. This is hugely a function of verbosity, elegance of the libraries and hot reload - JS absolutely crushes Rust along these axis. Meanwhile memory safety isn’t a big concern. But not just that, dynamic languages give you dev tools where you can inspect, edit and test changes and code at runtime and that’s the single biggest productivity boost you’ll find as a frontend dev. These are lessons learned over 20 years of developing for every UI platform under the sun. The modern web stack is simply going to get you to production with a far higher quality of UI in way, way less time. I could go on for a lot longer about this topic but suffice it to say: JS is an absolutely incredible language for fronted. It’s set of trade offs match the domain beautifully. I wish it was faster, but WebKit at this point is so much faster and less energy intensive than Blink that I’m extremely happy with app performance in it.

tayistay 4y ago
I think the jury is still out on whether rust is good or bad for UI. Once rust UI libraries are more mature we'll get a sense of it. There are some advantages of static typing, even for UI (see SwiftUI for example). I'll grant the pickiness of rust can be a challenge. Anyway give us some time to work on stuff. Here's my effort: https://github.com/audulus/rui https://github.com/audulus/rui
- 4y ago

Klonoar 4y ago

>What makes Electron slow is Javascript. This has been said as far back as when Slack engineers explained why they migrated away from system webviews to Electron here on HN.