Electron vs. Tauri
by Arrowmaster
14 subcomments
- 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 process needs reworked.
by sundarurfriend
3 subcomments
- > As you’d expect, this makes Tauri apps far more lightweight.
Note that lightweight compared to Electron does not mean it's actually lightweight. In my experience, Tauri apps are still pretty heavy and a constant drain on system resources; maybe they're 2x better (faster/lighter) compared to an Electron equivalent, but they're still at least 10x worse compared to native apps.
With a Tauri-based app (just like with Electron), I have to constantly remember to close the app at the soonest possible point in time, or I can tangibly feel the sluggishness it creates in the system performance. So if there's a native choice and a Tauri-written choice, I'd heavily prefer the native choice nowadays, even at the cost of some features.
by lone-cloud
2 subcomments
- - "Electron comes with a few rather significant drawbacks" Not going to mention them at all though?
- what possible reason could one have to use Next with Electron? Not everything needs to be in Next and there's no reason for SSR + Node.js API server (primary advantages of Next vs React) when the client and server are on the same machine. The author's solution is to wrap this with another dubious framework (Nextron looks abandoned and hasn't been updated for over 10 months btw) to force them to somehow work together. Like why?
- the idea behind Tauri to leverage the user's system's webview may sound like free real estate, but as many Cordova devs have previously found out, it's incredibly risky when you have no control of your own runtime. Desktop webviews are not a uniform layer. Ex. Webrtc is not supported on Linux webviews.
by dfabulich
1 subcomments
- > Lack of support for .appx and .msix bundles on Windows
https://github.com/tauri-apps/tauri/issues/4818
Whoa, I had no idea about that. Tauri is way less fully baked than I realized.
The bug goes on to explain that Tauri apps can't have Windows "package identity", which means that there's a bunch of Windows APIs you simply can't use in Tauri, including the notifications API.
Without package identity, IMO, Tauri isn't ready for primetime on Windows.
- 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!
by WhyNotHugo
0 subcomment
- I tried using Tauri a few weeks back, and the build system is an absolute nightmare.
I gave up after a few hours. The last issue I encountered was it trying to link udev and libinput. libinput is a library for writing compositors, and their website literally state "libinput is not used directly by applications". I've no idea why Tauri was trying to link this (and some rough ideas of why it wasn't working due to the absence of udev on that host), but at this point, I didn't care any more.
by anaisbetts
1 subcomments
- 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.
- As right now I try using Tauri 2 (work very much in progress, https://github.com/stared/rusted-doom-launcher), most AI suck at it, not getting basics about permissions. One thing that was a game-changer was using https://github.com/P3GLEG/tauri-plugin-mcp. Without that, Claude Code just tries things blindly and they work or not.
- 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
by schmorptron
0 subcomment
- 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?
by haideralshamma
2 subcomments
- 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
- "Compatibility issues across system webviews are exceedingly rare, especially for the major operating systems."
When it comes to CSS, there will be the same vendor issues that you have on websites. It's not a magic bullet.
by dangoodmanUT
0 subcomment
- As the author mentions, the problem right now is that electron is just too mature. It has solved most of the issues that non-desktop developers encounter when building a desktop app like a smooth(ish) build process, different kinds of build targets, working linux, etc.
by kristianp
1 subcomments
- How does Wails compare here? I'm guessing it's less mature than Tauri.
- What about neither?
If it must be Web, run the application headless and launch the system browser.
But really if 50 year olds can jungle between native and Web, so do you.
by testdelacc1
0 subcomment
- > Tauri doesn’t seem to be able to create Mac universal binaries from their arm64 and x64 subcomponents.
I think this problem will be “solved” on its own. According to the October Steam hardware survey, about 15% of macs are still on Intel, with the number dropping each month. In a year it’ll be less than 10%. The software side isn’t looking good either - Intel Macs have received their last OS update this year. In 2028 Apple will classify Intel Macs as “vintage”, ending most service and parts support.
I’m not making a judgement here on Apple’s decisions. But Tauri is unlikely to spend their time optimising for a small fraction (Intel) of a small fraction (mac users), which is also reducing over time. Their time is probably better spent getting Windows support up to scratch because Windows isn’t going anywhere.
- Would love to see these in comparison to desktop flutter.
by auggierose
0 subcomment
- Of course a lot of apps will not be able to live with the restrictions, but if you can write your app as a webapp (PWA), you should do that instead of using Electron or Tauri. I do it because I find either build system atrocious, and with webapps I can just use esbuild. Using Chrome for example, people can install webapps as desktop apps on any operating system, if they like, and the footprint is minimal.
- [dead]
- i had a better time vibe coding with gpt 4 with WAILS> vs any of these Electron> Tauri
- If they didn’t have the nodejs dependency then the Tauri bundle could be as small as 20mb.
Another pro not mentioned is that native integrations (i.e. obj-c on macos) are much easier to do since rust has great ffi integration with other native libraries.
The biggest pro to electron is that it has extensive plugins that are often widely used in production by large companies. But Tauri is definitely winning and any new project should use Tauri no matter what essentially.
Hacker News