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

71–80 of 85 posts

Re: Electron vs. Tauri

#71

Post by array_key_first »

lelanthran wrote: post #44
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!

TLDR; I'm keeping an eye on using LibWeb instead, which promises to be less bloated ------------------------------------- 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…

Just use Qt. QML is not exactly like HTML, but in a lot of ways it's better. HTML is primarily a document format, QML gets closer to the semantics of an application, but in a declarative format. It's also much, much faster and simpler to deploy.

Re: Electron vs. Tauri

#72

Post by yumraj »

Another alternate to Tauri is Wails if one prefers Go to Rust. I’m currently using Wails for something and it’s working out well so far.

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.

Re: Electron vs. Tauri

#73

Post by mdhb »

array_key_first wrote: post #71
lelanthran wrote: post #44

Earlier quoted context omitted.

TLDR; I'm keeping an eye on using LibWeb instead, which promises to be less bloated ------------------------------------- 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…

Just use Qt. QML is not exactly like HTML, but in a lot of ways it's better. HTML is primarily a document format, QML gets closer to the semantics of an application, but in a declarative format. It's also much, much faster and simpler to deploy.

Or Flutter for that matter, which is actually also incredibly nice to work with.

Re: Electron vs. Tauri

#75

Post by msla »

dfabulich wrote: post #18
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.

Well, it certainly isn't a stable ABI on Windows.

Re: Electron vs. Tauri

#76

Post by unmole »

dijit wrote: post #32
dfabulich wrote: post #18

Earlier quoted context omitted.

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

Which is wild when you consider the efforts the kernel goes to to avoid breaking userspace. Sometimes stifling innovation in UX. GNU libc has a lot to answer for here honestly.

> Sometimes stifling innovation in UX.

How does the Linux kernel maintaining backward compatibility stiffle UX innovation?

Re: Electron vs. Tauri

#77

Post by dijit »

unmole wrote: post #76
dijit wrote: post #32

Earlier quoted context omitted.

Which is wild when you consider the efforts the kernel goes to to avoid breaking userspace. Sometimes stifling innovation in UX. GNU libc has a lot to answer for here honestly.

> Sometimes stifling innovation in UX. How does the Linux kernel maintaining backward compatibility stiffle UX innovation?

You’re probably thinking of UX as being user interfaces and desktop environments.

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.

Re: Electron vs. Tauri

#78

Post by Arrowmaster »

hysan wrote: post #70
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…

Yup, came here to say this. After reading the article, it became abundantly clear that the author doesn’t support Linux and most of the article is just a summary of the common Tauri talking points that are out of date. To add data to this - Tauri is looking to allow embedding chromium as an option because the creator of Tauri acknowledged that it doesn’t work well on Linux. To the point where if Linux is a serious ta…

Thanks for the link. That's great info to know but it's only part of the problem. If they think changing out the renderer will fix everything then they haven't learned anything.

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.

Re: Electron vs. Tauri

#79

Post by zvr »

Another difference, not mentioned in the article or the comments till now, is the effort required for producing a legally compliant software distribution.

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.

Re: Electron vs. Tauri

#80

Post by hysan »

Arrowmaster wrote: post #78
hysan wrote: post #70

Earlier quoted context omitted.

Yup, came here to say this. After reading the article, it became abundantly clear that the author doesn’t support Linux and most of the article is just a summary of the common Tauri talking points that are out of date. To add data to this - Tauri is looking to allow embedding chromium as an option because the creator of Tauri acknowledged that it doesn’t work well on Linux. To the point where if Linux is a serious ta…

Thanks for the link. That's great info to know but it's only part of the problem. If they think changing out the renderer will fix everything then they haven't learned anything. 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.

Good to know. Every time I gave Tauri a shot, issues with the state of WebKit on Linux was always my first hard wall. I never got to even trying to make a production executable. Sounds like it’ll be a long time before this ever becomes viable for fully cross platform use cases.
Post reply on HN