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.
I've been a lifelong Linux user, and this makes me sad.
I don't know enough to comment about whether or not it's necessary, but any time I've tried to get anything working that wasn't updated recently, it was impossible.
Well impossible is a bit strong, the process ranges from:
- Find a forum post that links to some old .deb files and install them manually
- Install a newer version of a dependency and then recompile from source code, after spending an hour or two updating the program so it works with the new version of the dependency because the dependency changed its API for no reason (that one's not a Linux problem per se, but it wouldn't be necessary if the old one still worked!)
Better to download the Windows version and run it in WINE...
I really wanted to use tauri instead of electron, but the libwebkit it uses on linux is just too slow for modern CSS/html, from memory I managed to get single digit fps just scrolling the components page of daisy-ui. I am holding on for when they get a servo integration.
Sadly, every time that one guy posts his personal finance app on HN I try it and every time tauri gives me trouble to build, and when I fix whatever build errors it gives me it basically opens up a blank window and the app doesn't work (He now offers a Docker image which I can't help but feel is related to these difficulties).
lol Linux. The market share is laughably small vs the time and energy and cost it’d take an engineer or team of engineers to support Linux. Sure they could bundle electron but where’s the fun in that?
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.
Huh, I thought I'd seen notifications and app URI handlers in a Tauri app. Maybe they were using a custom Wix builder and not the Tauri template though.
> 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.
I'm curious what the impact on system resources is between a Tauri-based app versus the web app version opened in a browser window. If the features for both are the same, I imagine the resource utilization is also the same. The only exception might be that browsers such as Chrome will force inactive tabs to sleep.
Readwise Reader is one app I've compared both versions to, and I don't see much difference in resource usage for either version.
Last time I messed with Tauri my bin folder in my code/building directory ballooned to 10 gigs. If the final product is “lightweight” the development process surely is not.
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.
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.
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.
My current project uses Wails and a previous one used Tauri. I like Tauri a bit more but not enough to justify porting Go code to Rust. The primary difference I run into is how the JS <-> native interface is exposed, but this is very minor.
Tauri is much slower to build, I think this is just the nature of Rust though. Stats here. [1]
The author says “Namely, 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.
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.
"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.
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.
I've been a lifelong Linux user, and this makes me sad.
I don't know enough to comment about whether or not it's necessary, but any time I've tried to get anything working that wasn't updated recently, it was impossible.
Well impossible is a bit strong, the process ranges from:
- Find a forum post that links to some old .deb files and install them manually
- Install a newer version of a dependency and then recompile from source code, after spending an hour or two updating the program so it works with the new version of the dependency because the dependency changed its API for no reason (that one's not a Linux problem per se, but it wouldn't be necessary if the old one still worked!)
Better to download the Windows version and run it in WINE...
It's like they always say: Win32 is the only stable ABI on Linux.
I really wanted to use tauri instead of electron, but the libwebkit it uses on linux is just too slow for modern CSS/html, from memory I managed to get single digit fps just scrolling the components page of daisy-ui. I am holding on for when they get a servo integration.
The idea of AppImages is neat, but the implementation is awful and rarely works (except perhaps on Ubuntu and Fedora and extremely similar scenarios).
The main issue being that they're dynamically linked binaries, which is exactly what you want to avoid for their use case.
Using packages from your favourite distribution is usually your best bet.
Sadly, every time that one guy posts his personal finance app on HN I try it and every time tauri gives me trouble to build, and when I fix whatever build errors it gives me it basically opens up a blank window and the app doesn't work (He now offers a Docker image which I can't help but feel is related to these difficulties).
lol Linux. The market share is laughably small vs the time and energy and cost it’d take an engineer or team of engineers to support Linux. Sure they could bundle electron but where’s the fun in that?
> 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.
Huh, I thought I'd seen notifications and app URI handlers in a Tauri app. Maybe they were using a custom Wix builder and not the Tauri template though.
Yes it should be doable manually, not like this is a complex feature.
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.
> 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.
I'm curious what the impact on system resources is between a Tauri-based app versus the web app version opened in a browser window. If the features for both are the same, I imagine the resource utilization is also the same. The only exception might be that browsers such as Chrome will force inactive tabs to sleep.
Readwise Reader is one app I've compared both versions to, and I don't see much difference in resource usage for either version.
Last time I messed with Tauri my bin folder in my code/building directory ballooned to 10 gigs. If the final product is “lightweight” the development process surely is not.
That’s just Rust in general. But what you lose in disk space you gain considerably in optimized executables. The tradeoff is well worth it.
Hm, that shouldn't happen. It does use RAM for the web view, but an idle Tauri app won't use CPU any more than any other idle app or web browser tab.
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.
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
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!
This was recently on HN and I think it adds so much value to GPUI: https://github.com/longbridge/gpui-component/
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.
How does Wails compare here? I'm guessing it's less mature than Tauri.
My current project uses Wails and a previous one used Tauri. I like Tauri a bit more but not enough to justify porting Go code to Rust. The primary difference I run into is how the JS <-> native interface is exposed, but this is very minor.
Tauri is much slower to build, I think this is just the nature of Rust though. Stats here. [1]
1. https://github.com/Elanis/web-to-desktop-framework-compariso...
The author says “Namely, 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.
i had a better time vibe coding with gpt 4 with WAILS> vs any of these Electron> Tauri
Go is likely much easier to work with here than the other platforms imo
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.