Counterpoint: if you rewrite a Rust app, ANY Rust app and turn it into a perfectly rewritten Electron app, it will 100 percent still be shittier, bigger, slower and eat more RAM and CPU.
Counterpoint: if you rewrite a Rust app, ANY Rust app and turn it into a perfectly rewritten Electron app, it will 100 percent still be shittier, bigger, slower and eat more RAM and CPU.
Possibly but not guaranteed.
For desktop apps UI quality and rendering speed is paramount. There's a lot of stuff buried inside Chrome that makes graphics fast, for example, deep integration with every operating systems compositing engine, hardware accelerated video playback that is integrated with the rendering engine, optimized font rendering... a lot of stuff.
If your Rust UI library is as advanced and well optimized as Blink, then yes, maybe. But that's pretty unlikely given the amount of work that goes into the Chrome graphics stack. You absolutely can beat Chrome in theory, by avoiding the overhead of the sandbox and using hardware features that the web doesn't expose. But if you just implement a regular ordinary UI toolkit with Rust, it's not necessarily going to be faster from the end user's perspective (they rarely care about things like disk space unless they're on a Windows roaming account and Electron installed itself there).
Having worked on a graphical application in rust for a (albeit not a complex one) computers today are fast.. latencies top out at 3 ms with cpu based rendering in an application with just a few rendering optimizations.
The fact that you just draw on the screen instead of doing whatever html parsing / DOM/IR is probably doing it? And doing rendering on the gpu means extra delay in the processing moving from cpu to gpu and being a frame behind because of vsync.
Can you clarify this? Seems to me that no matter how you render your UI, it has to go to the GPU framebuffer at some point.
For any non-trivial case where I can enable GPU acceleration for an app, it's been anywhere from equivalent to much more responsive.
What apps have you experienced delays with by enabling GPU acceleration?
Where it really shows up is stuff like power usage and reliably hitting framerates even on slow machines with big hi-res monitors attached.
Point of information: I believe this project uses Tauri, which actually does use web technology and even JavaScript for rendering, it just does it with the native web renderer of the platform so you're not dragging around a superfluous extra copy of Chrome in RAM for each and every individual app:
"Write your frontend in JavaScript, application logic in Rust, and integrate deep into the system with Swift and Kotlin."
"Bring your existing web stack to Tauri or start that new dream project. Tauri supports any frontend framework so you don’t need to change your stack."
"By using the OS’s native web renderer, the size of a Tauri app can be little as 600KB."
So you write your frontend with familiar web technology and your backend in Rust, although it's all running in one executable.
I am curious if it would be all that much worse if your backend was also JavaScript, let's say in Node.js, but it certainly depends on what that back end is doing.
Comparing Rust with Electron is so weird. One is a language, the other is a lib/framework.
I think it’s clear what stack is typically meant by “an Electron app” and why using a blanket term like this is faster.
However, you could use Rust compiled to WASM in an Electron app, therefore the two aren’t even mutually exclusive.
For the OP's specified case, it is only a little language related. It is more a lib/framework related thing.
Tauri is the thing being implicitly compared with electron. Well worth checking out.
It's not, both can be apps.
This is akin to saying if you rewrite it in Assembly it would be better than Rust. True, but what are the tradeoffs? Why doesn't everyone write it in assembly?
It _would_ be bigger and eat more RAM and CPU. But that does not imply "shittier".
There are parameters like dev time, skills available in the market, familiarity, the JS ecosystem etc that sometimes outweigh the disadvantage of being bigger/slower.
You're pointing out the disadvantages in isolation which is not a balanced take.
All those parameters mentioned are exclusively for developers. End users don't care and will get a worse product when you choose Electron instead of doing it properly.
End users care that they get a product at all. Which they won't if it's too costly to make. There is a balance that is appropriate for each project. Or else we should all be writing machine code by hand.
Rust has been shown by Google to not be any less productive than other mainstream languages though.
Link? I’d love to learn more!
[citation_needed]
> All those parameters mentioned are exclusively for developers. End users don't care and will get a worse product when you choose Electron instead of doing it properly.
A sensible take wouldn't pick one or the other as unilaterally better regarding the abstract context of what a good product is. The web as a platform is categorically amazing for building UIs, and if you chose continued to choose it as the frontend for a much more measurably performant search backend, that could be a fantastic product choice, as long as you do both parts right.
> This is akin to saying if you rewrite it in Assembly it would be better than Rust
Not really. Nobody is rewriting GUI apps in Assembly, the reasons are obvious.
Dev time like cater for ever moving Node stack? (Not sure if it applies here because I'm not familiar with Tauri).
This is something I think a lot of people miss about Rust - outside of slow compile times and personal preference, there is no reason not to choose Rust over JavaScript/TypeScript (unless of course you're working in the browser). It does everything JavaScript can do, but it does it faster and with more stability. At the end of the day, these features pay out huge dividends.
And this isn't Rust zealotry! I think this goes for any memory-safe AoT language that has a good ecosystem (e.g. Go or C#): why use JavaScript when other languages do it better?
Rust's type system gymnastics compared to most languages goes quite a bit beyond preference. I can't see the overlap at all with dynamic scripting languages, two completely different tools for completely different problems.
TS has one of the more gymnastics-heavy type systems, IMO, and I think many if not most JS shops use TS.
TS is gradual though, Rust is all or nothing.
A world of difference between the borrow checker and a garbage collector.
> there is no reason not to choose Rust
Sounds like Rust zealotry to me, followed by a mild attempt to walk it back.
All of that is true, but technological choices aside it doesn’t take away from all of the points made by the parent.
I took that as the somewhat the point, and I think it was insightful. Your app will still be worse, but worse as result of your poor technology choices, not the arguments made here. Put together it may still be a bad move, but you would still get the greenfield effect.
Performance is a feature, I agree. Language choice matters to a degree. Shitty apps can still be written in “fast” languages.
[dead]