HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
tauri-apps
tauri
Rust2019–2026
tauri-apps / tauri

tauri

Build smaller, faster, and more secure desktop and mobile applications with a web frontend.

88Distinct people
95Mentions
2Explicit recommenders
112.8KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Build smaller, faster, and more secure desktop and mobile applications with a web frontend.

GitHub

Where it is used

The last source check was inconclusive. This does not establish whether a product uses it.

What people are saying

since this is for security: I'm quite uncomfortable with the way APIs are exposed to the browser instance that does the UI rendering. As far as I can see from the code,…

zemnmez used a recommendation phrase. 2 indexed comments match. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year95 dated mentions

Observed mentions: 2019-11-19 09:08:01 UTC to 2026-08-31 20:11:14 UTC.

01020302019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 16 mentions; 3 submissions, 13 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 17 mentions; 0 submissions, 17 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 30 mentions; 8 submissions, 22 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 12 mentions; 2 submissions, 10 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 9 mentions; 0 submissions, 9 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC101
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC16313
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC17017
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC30822
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC202
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC12210
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC808
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC909

What Hacker News says

95 sources
Sure. Tauri tries to claim its lighter than Electron by not including a full web browser in its runtime and instead using the system renderer. But Linux doesn't have a universal system renderer like Windows and Mac does so it uses Webkit2Gtk on Linux. Libwebkit is an absolute mess of a library. It hardcodes the path to /usr which doesn't work in AppImages resulting in this[1] hack of a fix that replaces `/usr` with `././`. This problem isn't unique to Tauri as I have seen apps using Wails copy this same trick to package their AppImages. Now the problem with libwebkit goes even deeper because Tauri uses libwebkit2gtk-4.1 after moving away from 4.0. When you build an AppImage you want to do it on the oldest possible distro you want to support because it will be built against GLIBC of that distro release. Due to how most devs release apps no
Read the rest
w, that means they compile against an Ubuntu LTS release because Ubuntu is the only option with Github Actions[2]. The first LTS version of Ubuntu with 4.1 is 22.04, so now by default you can expect every Tauri (and also probably Wails) AppImage to be built against GLIBC 2.36. But theres a bug in the interaction of older libwebkit2gtk and newer freetype that happens when you use an AppImage built on Ubuntu 22.04 on a newer distro. It crashes when displaying an emoji character. Freetype is one of the libraries you cannot include in an AppImage but you must include libwebkit2gtk, the solution is to use a newer libwebkit2gtk but thats only available in Ubuntu 24.04 and bumps the GLIBC to 2.39. Do you see how much of a mess this usage of libwebkit2gtk in an AppImage turns out to be. And moving beyond that, the Tauri devs has an absolute disdain for the AppImage format and treat it as a 2nd class platform as you can see in this[3] PR where AppImage developers tell the Tauri devs to update to newer tools instead of mirroring the old obsolete broken tool that was taken down. This also meant that AppImages created by Tauri's build tools depended on libfuse2 being installed on the system while newer AppImages using the type2-runtime do not anymore. I believe Tauri has finally moved forward and stopped doing this recently. Electon is no better on this and electron-builder uses an outdated hardcoded tool that makes bad AppImages that depend on libfuse2 too. I do like the AppImage format, but I do not believe anything that uses libwebkit2gtk-4.1 is fit to be distributed as an AppImage at this time. This means that Tauri (and by extension probably Wails, and some of these other NOT Electron frameworks) are not fit to be truly called cross platform. It does look like Tauri was making progress on Flatpak documentation so app developers could have a second cross distro packaging method. Ideally I think any framework that wants to label itself as cross platform should make it easy to package both AppImage and Flatpak and not run into the above libwebkit2gtk issues. [1]<https://github.com/tauri-apps/tauri/blob/ad0b98a2329e369364e...> [2]This is not entirely true, you can use a docker image inside the Github Actions Ubuntu VM or a sysroot but that is beyond even most expereinced app devs to setup. [3]<https://github.com/tauri-apps/tauri/pull/13863>
In Show HN: Linux server management over SSH – written in Rust and Tauri
A word to the wise: similar to how foam is mostly air, Tauri is mostly marketing. Most of those 15MB "lightweight" bundles expand to 2 GB+ RAM in practice. Of course, devs still shamelessly (ignorantly, in all likelihood) call the apps "lightweight", while taking up, say, 6 GB of RAM for a 5 button UI. Tauri have also proven reticent [0] to correct the record. One supposes the sole advantage of sharing memory with other Tauri apps is not a sufficient sell to overcome Electron's single-browser-engine advantage. A pure Rust app takes up ~60 MB for the same UI, with a large portion of that going towards graphics (wgpu table stakes). [0] https://github.com/tauri-apps/tauri/issues/5889
In Show HN: Sycamore – next gen Rust web UI library using fine-grained reactivity
I have also used Tauri for one of my private apps, and using the OS's webview just doesn't work for me, so for my next stuff I'm probably going to use Electron as well since you can embed the webview. Yeah, it's bloated, but I'm so tired of things not working properly on Wayland without disabling this and that with random env vars and not able to do a fully OOTB single portable AppImage build on Linux. I can either make it work in Kubuntu + Arch (building on Ubuntu), or Arch + Fedora (building on Arch), but not all 3. I tried Uno Platform and AvaloniaUI last year but I had similar problems there with external drag 'n' drop not working on Wayland and the difficulty in writing your own advanced components of which there are oodles to choose from using React/Vue/Solid/Svelte. I'm not rewriting that other app in Electron, so for Tauri (the de
Read the rest
velopment of which largely seems to have stalled?) I'm hoping this[1] will solve my Linux hurdles. Going to try that branch out. [1]: https://github.com/tauri-apps/tauri/pull/12491 And this is just desktop Linux. I used to care about Windows but stopped building for that.
In Claude is an Electron App because we've lost native
I have been using Tauri for a macOS app I'm making[1] and it has been great. The app is only 11MB and I've had most of the APIs I'd need. However, there are still some rough edges that have been annoying to work with. I think for my next project I will actually go back to electron. There are two issues that caused me pain: 1. I can't use Playwright to run e2e tests on the tauri app itself. That's because the webview doesn't expose the Chrome DevTools Protocol, and the tauri-driver [2] does not work on MacOS. 2. Security Scoped Resources aren't fully implemented which means if a user gets the app through the app store the app won't be able to remember file permissions between runs [3]. It's not too much of an issue since I probably won't release it on the app store, but still annoying. But I hope Tauri continues to grow and we start seeing
Read the rest
In Claude is an Electron App because we've lost native
There is a ton of work going into a Tauri based on CEF. https://github.com/tauri-apps/tauri/tree/feat/cef My hope is this still acts like a library that multiple Tauri instances share. That would still have the upside of Tauri's shared library architecture (boo statically compiled programs, what a waste of precious ram!) while still letting us have a viable runtime. First app load might not be lightning fast but second app load is hopefully faster!! The OS webviews range from mediocre to absolute garbage; this to me would be a great improvement, that makes me happy!
In Electrobun v1: Build fast, tiny, and cross-platform desktop apps with TypeScript
> 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.
In Electron vs. Tauri

Showing the 15 most recent of 95 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.