Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Electron vs. Tauri

dolthub.com

Post reply on HN
Print view View original

51–60 of 85 posts

Re: Electron vs. Tauri

#51

Post by anaisbetts »

Tauri's approach of using the system Webview just doesn't scale to millions of users. You will end up having to tell your customers, "In order to fix the bugs in our app, you need to install a new version of your OS", or in the case of Apple, sometimes even saying, "You need to buy a new computer to use our app". It's not a great conversation to have.

Philosophically, it also optimizes something that doesn't really matter much in 2025, download and disk space - despite the perceptions, the system Webview usually uses the same order of magnitude memory as Electron; maybe a little less, but not a Lot less. We can see the WhatsApp rewrite on Windows to use WebView2 as evidence of that.

The one time that Tauri is legitimately better though, is if you've got a lot of Rust code that you want to integrate - GitButler for example uses Tauri and it works for them because they have a lot of Git systems code and it's all in Rust.

Re: Electron vs. Tauri

#52

Post by PinkFluffyLlama »

anaisbetts wrote: post #51

Tauri's approach of using the system Webview just doesn't scale to millions of users. You will end up having to tell your customers, "In order to fix the bugs in our app, you need to install a new version of your OS", or in the case of Apple, sometimes even saying, "You need to buy a new computer to use our app". It's not a great conversation to have. Philosophically, it also optimizes something that doesn't really m…

We (GitButler) however keep running into packaging issues that make all but a very small handful of linux distros "usable". There are also numerous papercuts that we keep getting due to Tauri being comparably less mature.

We've been making steps towards moving away from Tauri. We now already have the capability to run our rust backend as a web-server and use the frontend in a regular browser. One of the next steps is to package the frontend into an electron app, and run the web-server as a sidecar process.

While there may be size downsides to packaging an entire browser - size isn't really a big issue compared to the program simply not working on a large user demographic.

Re: Electron vs. Tauri

#53

Post by nicoburns »

lelanthran wrote: post #44
mootoday wrote: post #19

My personal favorite to keep an eye on is https://www.gpui.rs/ . It's what Zed(.dev) is based on. While not quite ready for prime time from what I understand, if Zed is the reference implementation, I'm sold!

TLDR; I'm keeping an eye on using LibWeb instead, which promises to be less bloated ------------------------------------- Honestly, we're solving the wrong problem by using something like Electron, webit, Tauri, etc. We're aiming for perfect feature parity with web browsers. Instead, I want a good way to declare my UI in a subset of HTML, a subset of CSS and optionally a subset of Javascript. That's it, as far as web…

How about HTML, CSS, and Rust? (cutting out the JS engine removes a lot of the bloat)

I'm building a web engine specifically targeting application development use cases here: https://github.com/DioxusLabs/blitz. Binary sizes are in the 5-15mb range (depending on which features you enable).

Re: Electron vs. Tauri

#54

Post by notpushkin »

wg0 wrote: post #45
Arrowmaster wrote: post #12

The author has obviously never tried Tauri on Linux. I've never seen one of their AppImages work correctly. Every project uses the upstream GitHub action to build binaries and it compiles dynamically linked binaries limited to the glibc from the Ubuntu 22 or 24 VM used. Xdg-open is often broken too from broken environment variables in the AppImages, so you can open a link in the default web browser. The entire build…

Tauri finding and loading WebView is not the only game in town. There's wails too for golang. I don't understand the obsession with trimming the disk size at the expense of stability. The WebView these libraries find isn't the one your JS bundle is hoping for and an upgrade of the WebView isn't an option then what?

It's not only the disk size, it's also RAM.

Re: Electron vs. Tauri

#55

Post by phaser »

I seem to be the only one with some degree of success with Tauri :)

After someone suggested here in HN I switched Microlandia[1] from deno-webview[2] to Tauri.

So far, it’s been a pretty good experience in Windows and macOS, of all the bug reports I received, zero are related to Tauri. Only one caveat: For Steam Linux, I had to package the game in electron after spending an entire weekend in library hell trying to get it to work in the Steamworks sniper SDK.

1. https://explodi.itch.io/microlandia

2. https://github.com/webview/webview_deno

Re: Electron vs. Tauri

#56

Post by sipjca »

phaser wrote: post #55

I seem to be the only one with some degree of success with Tauri :) After someone suggested here in HN I switched Microlandia[1] from deno-webview[2] to Tauri. So far, it’s been a pretty good experience in Windows and macOS, of all the bug reports I received, zero are related to Tauri. Only one caveat: For Steam Linux, I had to package the game in electron after spending an entire weekend in library hell trying to ge…

I've also had some degree of success with Tauri but not without pains. But to be fair most of the pains have come from the state of Linux DE (it's absolute hell if you ask me)

For the most part, things just work on MacOS (Windows I don't use much, but I don't get that many bug reports from Windows, so it must work alright. I would guess I have 50k Windows users?).

I don't have any experience with Electron, but in many ways I assume it probably is much more robust of an experience than Tauri. A lot of stuff has felt shaky to me, yet it does work. It's just not always a confidence inspiring experience. But again, maybe this is just the state of cross platform experiences generally? I don't know because I don't have enough experience to say

Source, I'm the author of: http://github.com/cjpais/Handy

Re: Electron vs. Tauri

#57

Post by schmorptron »

What is the implementation difference between using the system WebView (fragmented, especially bad under linux) and using one shared tauri-base runtime that only gets breaking changes updates every 2 years or so so there aren't twenty different ones running at the same time and it ends up like electron?

Would bundling one extended support release of chromium or firefox's backends that are then shared between all tauri apps not suffice?

Re: Electron vs. Tauri

#58

Post by sipjca »

Arrowmaster wrote: post #12

The author has obviously never tried Tauri on Linux. I've never seen one of their AppImages work correctly. Every project uses the upstream GitHub action to build binaries and it compiles dynamically linked binaries limited to the glibc from the Ubuntu 22 or 24 VM used. Xdg-open is often broken too from broken environment variables in the AppImages, so you can open a link in the default web browser. The entire build…

Yeah.. It's pretty damn hard to get working at all, and the systems it does seem to work on is quite limited as well. And also the developers of Tauri largely have seemed to have given up on Linux (which to some degree I understand, it represents a tiny amount of users for 99% of the problems due to the massive diversity in the ecosystem of Linux DE)

I fight with GitHub Actions on this all the time, and damn near think about running dedicated instances just to build from.

Re: Electron vs. Tauri

#59

Post by sipjca »

bpev wrote: post #25
haideralshamma wrote: post #23

I am building an open source desktop app in Tauri [1]. One of the issues I encountered was having to duplicate and sync types between the TypeScript frontend and Rust. On the other hand, Rust proved to be a great language with a sizeable ecosystem for building application backends. [1]: https://github.com/haideralsh/prompt-lab

fwiw, I think the most comprehensive cross-typing work done here has been specta: https://github.com/specta-rs/tauri-specta

yes, it works, I would recommend it even if it's a bit awkward at times

Re: Electron vs. Tauri

#60

Post by max-privatevoid »

warangal wrote: post #39
Arrowmaster wrote: post #12

The author has obviously never tried Tauri on Linux. I've never seen one of their AppImages work correctly. Every project uses the upstream GitHub action to build binaries and it compiles dynamically linked binaries limited to the glibc from the Ubuntu 22 or 24 VM used. Xdg-open is often broken too from broken environment variables in the AppImages, so you can open a link in the default web browser. The entire build…

Using `zig-cc (clang)` to set a particular `LibC` version is one of the best decisions i have made, and saved me from those meaningless libC mismatch errors!

It's insane that Zig was needed to achieve this, instead of a preprocessor definition like "#define GLIBC_MIN_COMPATIBLE_VERSION GLIBC_2_40".
Post reply on HN