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.
Here's the code: https://github.com/DioxusLabs/dioxus/tree/master/packages/in...
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.
My suggestion in general not specifically for you is to Profile the slow part of the app and find the problem.
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).
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 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.
Consider VS Code, software generally considered to be fast enough: every single interaction is handled by a dedicated, hand written, event handler which wherever possible directly modifies existing DOM nodes with the smallest amount of change possible.
This is miles from React. It's what SolidJS aims to do, but the state of the art here seems to be about equivalent to ASM vs Compiled C in 1980: an expert can get miles better performance by dropping down as far as possible in the stack themselves. Not to mention SolidJS forces you into their "lens" of JS, where variables are functions and functions are auto-invoked at the compilers will. And don't even think about refactoring an expression inside JSX to be outside of it or else you'll break all of reactivity. Unless you wrap it in another function, of course.
OTOH I read that and say it's precisely a React issue/bottleneck :)
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.
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.
Here's my effort: https://github.com/audulus/rui
On the web I have my app fully running on one side, and my code on the other. I make a change, it shows. Even if it’s inside a deeply nested pane, with some stateful stuff going on. And if things go wrong, I open the console and I inspect everything, change things, run some code, and fix it.
I actually tried SwiftUI on my last app I was making for months before I gave up. It felt like going back to the stone ages.
And that’s Apple putting their full effort behind something with decades of UI stuff already in place!
Not to mention my files kept getting too big for the Swift syntax checker all the time, but I’m sure they can fix that.
Lately, however, I've worked on a Mastodon Client written in Dioxus (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.