We Chose Tauri over Electron for Our Performance-Critical Desktop App | Hacker News Reader

We Chose Tauri over Electron for Our Performance-Critical Desktop App

gethopp.app

42 pointsiparaskev22 comments

While I like Tauri being light weight, its rust backend and support for mobile, I'm considering moving to electron now.

The webviews on different platforms are very fragmented. they support different feature sets and have different bugs. For example, on mac, I have seen svg and pdf rendering bugs I don't know when they will be fixed. I can't predict their behaviors on platforms I have no access to.

Tauri is also too young, I have seen its new window system crashes on users' machines. And as for the sidecar/external binary feature, Tauri doesn't fix the rpath when packaging, you will have to solve it using manual solutions.

I love rust, but many solutions are only available in c++. rust bindings are usually maintained by hobbyists and rarely updated. I have no energy to fix the binding issues.

I'm now going back to electron, so my frontend can use webgpu. As for the backend, I'm planning to write nodejs addons in c++ and rust.

Fair points all of them.

With the side car support we haven't faced any issues so far tbh (on windows and macOS).

Also I agree that the lack of wgpu is annoying. This is why for our cursor rendering (our sidecar) we are just using winit with wgpu. We are thinking of trying egui for our cursor rendering and then maybe try to integrate it with Tauri and remove the sidecar completely.

Our frontend is quite simple so we don't need wgpu there. Though I agree 100% that with electron you will have less surprises.

Hopefully our experiment won't come back to bite us and we will be able to contribute back to the community.

We have done this move at Caido despite being a rust shop for the reason you mentionned. The webviews on OS are garbage in 25-35% of the time and will cause 90%+ of your bug report.

Switched to electron and moved on. Almost nobody cares about the memory footprint and the binary size. But they will care then app is half broken on their 9 years out of date webview...

If it's so performance critical why not do a native UI?

Costa here, post author.

For the performance critical part, which is the screen-sharing and remote control, everything is done from Rust which is low level and gets the job done.

Native UI in this case wouldn't offer us much more. There is a case that maybe it could be faster in the video rendering in comparison from the browser's <video> tag, but we have not make any tests yet, maybe we should test this in the future.

The advantage of electron was that the client side scripts in the renderer and the backend use the same language and the two can share data easily (although not so much these days given disabling that is done for security). Whenever I use electron, I have communication between the backend and the renderer client side scripts go over a socket. This made the code fairly portable, such that I was able to do proof of concept port of an electron application I wrote for use in health care to a WebKitGTK version written in around 100 lines of C with the backend nodejs process still running. Interestingly, this cut memory usage in half, with half of the remaining memory usage being the nodejs process. I assumed replacing nodejs with pure C code would lower memory usage even further, but this ran on a CM4, so there was no pressure to reduce memory usage, and I abandoned the C port because using electron as is was more convenient.

There really is not much special about electron or tauri. You can do the same thing in any language that can use WebKit as a library.

TBH we are also doing something similar, where we have a separate process that creates a winit overlay window and draws the remote cursor with wgpu, this process also handles screen sharing and remote control.

The process with the tauri backend are communicating via a socket, so you could say it doesn't really make a difference if it is electron or tauri in the end of day.

Though we are thinking of using egui for the rendering process in the future and then we could have the opportunity to integrate it in the main app (tauri has an egui integration for v1, which unfortunately is broken for v2).

I miss my wxwidget days, when we had true cross platform devs.

Yes, it came with drawbacks, but it felt snappy and bloatfree.

Whereas modern apps feast on RAM and CPU... Having an app boasting light weight, when before we had 16 to 64MiB for WHOLE system feels ironic

Is wxwidget not a viable choice in 2025 anymore?

It is, from a tech point of view. It isn't from a workforce point of view. Which makes me sad, but still remains a fact.

I discovered Tauri as a way to package my HTML/JS game in a small desktop application. I felt like Electron would have so much overhead or complexity that it wouldn’t be worth it. The only problem I’ve encountered is making sure to use .mp3 or .wav instead of .ogg since not all webviews support .ogg

I was expecting the answer to be "code size", since that's Tauri's largest concrete advantage. Instead it's because they want to be able to directly run performance-sensitive Rust code in the main process, and because Tauri has a built-in library for spawning sidecar processes that's slightly higher-level than what Electron offers, at least if you want the process-spawning logic to live in the renderer process.

The latter point seems real but kind of minor. For the former, I'm curious whether they considered using napi-rs or neon to call Rust code from within a Node.js process.

TBH no we haven't considered them. Our initial approach is to keep things as simple as possible and have everything performance critical in one language and if possible in the same process (which is not the case for now). Having said that, if we see that there are better alternatives that will make the project easier to maintain and develop, we will apply them.

If the big architectural differences between Electron and Tauri came out in Electron's favor for your project (i.e., if differences between rendering engines were a real problem in practice), then I'd say it would almost certainly be a mistake to choose Tauri just to avoid having to do FFI. Of course, if rendering engine differences aren't a problem in practice, then the choice is much lower-stakes and what you're currently doing will probably be fine.

I totally agree. If it turns out that we are getting too many bugs because of the different web engines, then we will ditch tauri for sure.

Are the memory benchmarks measured correctly?

This tauri issue suggests the common measurement approach might be wrong

https://github.com/tauri-apps/tauri/issues/5889

Also would be better to have specific startup time instead of "fast" (which is strange since electron is not known for fast startup)

We might have missed something here, but the `tauri://localhost` is the Webview memory in https://gethopp.app/blog/tauri-vs-electron#memory-usage, and the executable path is: `/System/Library/Frameworks/WebKit.framework/Versions/A/XPCServices/com.apple.WebKit.WebContent.xpc/Contents/MacOS/com.apple.WebKit.WebContent`. The measurements were taken on macOS.

I keep seeing more and more apps being built with tauri, without any big issues. Yaak for example is built with tauri and it's pretty great :) i can't remember much other example from the top of my head, but it's definitely becoming a solid options

its the same memory usage. its hidden by the OS.

its less efficient because you can only ever pass messages to the webview. you cant compile modules and integrate like you can with Electron.

webviews are a naieve solution only useful for basics and even then is outdone by any other cross platform UI.

Tauri mention it is more secure than electron. What exactly makes tauri more secure?

Tauri v2 is very good!

Agree, and really minimal breaking changes, exceptionally smooth migration for us. We start a few months before stable v2 and we did not have any problem upgrading.

Reply on news.ycombinator.com