Hacker News

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. dfabulich 5 hours ago ... 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. 01HNNWZ0MV43FF 5 hours ago ... 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 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.