Regarding point #4, I think the clear winner is Tauri. I'll clarify -- While writing in Node is great if you don't know Rust, your users are being shipped an entire Node runtime, which has size, memory, and security issues. So in this case Electron has a "better" DX completely at the cost of the user. Tauri has JS/TS APIs, but if you need to do extensive backend work then it requires some learning at the benefit of y…
You're implying that application written in Rust would not have no size, memory and security issues. That is of course not true.
The downside of that control though is an application that's arguably a little too specifically targeted — it's understandable wanting to target the same engine but if your app breaks with different but reasonably recent versions of chromium I would say it's too brittle. It also widens attack vectors considerably when your entire userbase is all on the same probably-outdated build of electron-bundled chromium.
System webviews on macOS aren’t updated after a certain point, so Tauri is not necessarily always a win re: your final point.
But that's an Apple problem, not a "you" problem in that case. In Electron the security burden for tracking Chromium CVEs and sending updates out is entirely yours, whereas with Tauri you outsource it. In Electron, Chromium CVEs are your CVEs. In Tauri, Safari CVEs remain Apple's CVEs and technically entirely outside the scope of your application bundle. The trade-off for "old macOS webviews" is that it's not your problem other than general, basic old pre-Chromium hegemony HTML kindness of building web apps that gracefully fail if features aren't available, which is probably what you should do anyway?
Regarding point #4, I think the clear winner is Tauri. I'll clarify -- While writing in Node is great if you don't know Rust, your users are being shipped an entire Node runtime, which has size, memory, and security issues. So in this case Electron has a "better" DX completely at the cost of the user. Tauri has JS/TS APIs, but if you need to do extensive backend work then it requires some learning at the benefit of y…
You're implying that application written in Rust would not have no size, memory and security issues. That is of course not true.
Do you think it's unreasonable to assume that an app written in Rust will be smaller, use less memory and be safer than a similar app written in JavaScript?
I have been using Tauri to develop a Kubernetes IDE: https://github.com/nirops/yakiapp One additional thing from my experience, is if using Rust as a backend, the turnaround time for hot loading Rust changes is not trivial. This leads to longer times in building things vis-a-vis building in Electron with .ts/.js backend.
Mold linker cut down a lot of the build time when we were writing a tauri app, but the build times were still .. not my favorite.
I know there's probably docs somewhere, but what was the process to integrate mold into your build chain? Is it involved or fairly easy? I just heard of this for the first time and wondering if it could be useful to cut down build times in all my rust libs/apps...
You're implying that application written in Rust would not have no size, memory and security issues. That is of course not true.
Do you think it's unreasonable to assume that an app written in Rust will be smaller, use less memory and be safer than a similar app written in JavaScript?
I think it’s safe to assume that of anything written in something which doesn’t bundle an entire browser.
Though I do think it’s unrealistic that the legions of JavaScript devs are going to learn rust to make simple desktop apps because it doesn’t really have a reputation of being an easy language to learn.
System webviews on macOS aren’t updated after a certain point, so Tauri is not necessarily always a win re: your final point.
But that's an Apple problem, not a "you" problem in that case. In Electron the security burden for tracking Chromium CVEs and sending updates out is entirely yours, whereas with Tauri you outsource it. In Electron, Chromium CVEs are your CVEs. In Tauri, Safari CVEs remain Apple's CVEs and technically entirely outside the scope of your application bundle. The trade-off for "old macOS webviews" is that it's not your pr…
Your users don't care whose fault it is. Your app isn't working. You can choose to cut those users off, and that's totally an option...sometimes.
Mac users are probably a little more tolerant of this than non-Mac users, because of the general upgrade treadmill, but whether you can get away with it is a question only you can answer for your app.
You're implying that application written in Rust would not have no size, memory and security issues. That is of course not true.
Do you think it's unreasonable to assume that an app written in Rust will be smaller, use less memory and be safer than a similar app written in JavaScript?
> Do you think it's unreasonable to assume that an app written BY ME in Rust will be smaller, use less memory and be safer than a similar app written in JavaScript?
No, it won't be. You gotta weigh years if not decades of Node/JS experience vs 0 years of Rust experience of the average dev. Development time will be far shorter too.
My impression is that Electron can wrap whatever backend you want to use. Is that not the case?
I've embedded a rust logic core into electron, so yes, anything that can expose a C API can be loaded into electron. That said, after playing around with Tauri a bit I have to say it makes it magnitudes easier to embed rust. So if your target is rust, it's a much nicer option.
Tauri supports all languages, as long as they're Rust.
Calling this a "real world application" is a big stretch imo...Javascript's problems really come to the forefront when implementing complex logic in the backend - Rust's excellent type system helps a lot with that.
However, if you have an app that has a lot of interactivity, using the web_sys API is a huge pain that basically caused me to end development on my side project. Working with DOM APIs in Javascript is so much easier than working with them in Rust.