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.
> Starting with the Windows 10 Creators update and in all Windows 11 versions, supported links clicked in Microsoft Edge Legacy will launch the corresponding app. Supported links clicked in supported browsers (for example, Microsoft Edge Chromium, Firefox, Internet Explorer, etc.), will keep you in the browsing experience.
I can think of two ways to interpret it, neither of which seems good:
1) It doesn't work at all in any modern browser, and "supported" is the term Microsoft has chosen to describe this state of affairs?
2) Microsoft is sneakily installing a Firefox extension to subvert URL handling and embed UWP apps inside Firefox ("the browsing experience")?
[1] https://learn.microsoft.com/en-us/windows/apps/develop/launc...
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.
Readwise Reader is one app I've compared both versions to, and I don't see much difference in resource usage for either version.
There's new-ish build.build-dir setting that lets you redirect Cargo's temp junk to a standard system temp/cache directory instead of polluting your dev dir.
If it’s just logs, I would prefer to redirect it to /dev/null.
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 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.
GNU libc has a lot to answer for here honestly.
How does the Linux kernel maintaining backward compatibility stiffle UX innovation?
But sometimes a user is an api consumer.
There’s plenty of horrible kernel functions with footguns in Linux, but they won’t be improved due to “never break userspace”
theres lots if examples if you need specifics. readdir, epoll, futumesat (and ufutumesat), etc.
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 think that's the issue: https://github.com/electron/electron/issues/41066
Not even sure who to blame in this situation.
Tauri itself seems fine but the packaging in AppImage is exactly as you describe, or EFL just breaks.
They do have an effort to use Chromium Embedded Framework for rendering the webview, it's potentially much more stable in Linux. [1] It is nowhere near finished but you can run the cefsimple example, and it rendered me a window in Wayland.
CEF is also bundled in many distros, like Fedora 43, so if it can be linked with Linux distros version of CEF, then the binary stays smaller.
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?
I fight with GitHub Actions on this all the time, and damn near think about running dedicated instances just to build from.
The upstream projects aren’t in a place to support this yet so this feature didn’t make it into Tauri v2. I’ve been tracking this for a long time and hope that they will make it possible in v3.
Their build action creates seriously flawed AppImages for Linux for multiple reasons that have nothing to do with the renderer but with the AppImage creation process.
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.
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!
-------------------------------------
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 support goes. I don't need support for 1999 HTML/CSS, or special cases for animation in CSS, etc.
What I actually need for native applications is support for desktop/OS integration. Things like taskbar/panel icon control, notifications (not just toasts), access to the file system that doesn't use Javascript inside node.js, running tasks in the background independent of the GUI (after the GUI is closed, I expect the browser engine to end, freeing up all that RAM).
Striving to maintain feature parity with actual web-browsers eats up a lot of dev effort, so instead of targeting a sane subset of HTML, CSS (and optionally Javascript) it's simply easier to use an existing browser engine, which brings in the bloat and difficulty.
"Perfect is the enemy of good" has never been truer: I don't need everything that webkit, chrome, servo, etc provides when writing a native application, but "bloated" are the only options.[1]
Personally, I'm waiting for some free time, or a week off, to look into LibWeb (the SerenityOS engine, currently used by Ladybird browser). I think that creating a simple FFI around it is probably a better use of my time than doing the debug dance with Tauri and similar; at the end of the dance I'll still have a heavily bloated thing tied to an engine better suited for writing browsers than for writing apps.
---------------------------
[1] Not sure where Sciter lands on this.
It's not ready yet (it does layout HTML semi-properly, but it still needs some polishing and the desktop integration is currently not working, only the layout), I hope can get a release of it out before Christmas.
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).
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 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.
When it comes to CSS, there will be the same vendor issues that you have on websites. It's not a magic bullet.
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.
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.
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.
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
Would bundling one extended support release of chromium or firefox's backends that are then shared between all tauri apps not suffice?
There are some pro/cons but Wails and Tauri seems to be similar in principal. Tauri can also target mobile platforms it seems which Wails can’t is one big difference.
What are the technical limitations for this? I honestly know very little about webviews on linux.
All's well with using FOSS libraries, but the licenses have to be respected. So you have to collect license information and comply with the license terms. For GPL and LGPL licensed components, one had to make the complete corresponding source code available. For permissively licensed components, one usually has to provide the copyright notices.
Including the whole Chromium (as in the case of Electron) does not make this easy. Creating a Tauri-based legally compliant distribution is much less effort.
aabhay•2mo ago
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.