Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Electron vs. Tauri

dolthub.com

Post reply on HN
Print view View original

11–20 of 85 posts

Re: Electron vs. Tauri

#11

Post by TingPing »

01HNNWZ0MV43FF wrote: post #4
dfabulich wrote: post #3

> 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'…

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.

Re: Electron vs. Tauri

#12

Post by Arrowmaster »

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.

Re: Electron vs. Tauri

#13

Post by TACIXAT »

kristianp wrote: post #9

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...

Re: Electron vs. Tauri

#14

Post by 01HNNWZ0MV43FF »

sundarurfriend wrote: post #5

> 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 E…

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.

Re: Electron vs. Tauri

#15

Post by WhyNotHugo »

Arrowmaster wrote: post #12

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…

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.

Re: Electron vs. Tauri

#16

Post by WhyNotHugo »

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.

Re: Electron vs. Tauri

#18

Post by dfabulich »

Arrowmaster wrote: post #12

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…

It's like they always say: Win32 is the only stable ABI on Linux.

Re: Electron vs. Tauri

#20

Post by brainless »

mootoday wrote: post #19

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/
Post reply on HN