[HN Gopher] We Chose Tauri over Electron for Our Performance-Cri...
___________________________________________________________________
We Chose Tauri over Electron for Our Performance-Critical Desktop
App
Author : iparaskev
Score : 25 points
Date : 2025-04-11 10:53 UTC (12 hours ago)
(HTM) web link (gethopp.app)
(TXT) w3m dump (gethopp.app)
| billconan wrote:
| 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.
| iparaskev wrote:
| 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.
| hoofedear wrote:
| 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
| ryao wrote:
| 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.
| iparaskev wrote:
| 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).
| nottorp wrote:
| If it's so performance critical why not do a native UI?
| konsalexee wrote:
| 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.
| anxman wrote:
| Tauri v2 is very good!
| konsalexee wrote:
| 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.
| ramon156 wrote:
| 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
| jenadine wrote:
| Tauri mention it is more secure than electron. What exactly makes
| tauri more secure?
| ameliaquining wrote:
| 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.
___________________________________________________________________
(page generated 2025-04-11 23:02 UTC)