If it's so performance critical why not do a native UI?
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.
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
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.
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)
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
Tauri mention it is more secure than electron. What exactly makes tauri more secure?
Tauri v2 is very good!
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.
[flagged]
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.