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

41–50 of 85 posts

Re: Electron vs. Tauri

#41

Post by noir_lord »

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…

En Croissant and Pawn Appetite use Tauri (chess interfaces), neither ever works, got so annoying I just setup docker to build them on fedora and copy the binary out via scratch stage, needed to install one library and now both work.

Tauri itself seems fine but the packaging in AppImage is exactly as you describe, or EFL just breaks.

Re: Electron vs. Tauri

#42

Post by Ciantic »

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…

Yeah, I switched to Linux and my single Tauri app was not cooperating.

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.

[1]: https://github.com/tauri-apps/cef-rs/tree/dev/examples

Re: Electron vs. Tauri

#44

Post by lelanthran »

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

Re: Electron vs. Tauri

#45

Post by wg0 »

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…

Tauri finding and loading WebView is not the only game in town. There's wails too for golang.

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?

Re: Electron vs. Tauri

#46

Post by dangoodmanUT »

As the author mentions, the problem right now is that electron is just too mature. It has solved most of the issues that non-desktop developers encounter when building a desktop app like a smooth(ish) build process, different kinds of build targets, working linux, etc.

Re: Electron vs. Tauri

#47

Post by fschuett »

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…

You are looking for https://azul.rs - which I wrote to finally fix this whole "Electron" situation: https://azul.rs/reftest

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.

Re: Electron vs. Tauri

#48

Post by stared »

As right now I try using Tauri 2 (work very much in progress, https://github.com/stared/rusted-doom-launcher), most AI suck at it, not getting basics about permissions. One thing that was a game-changer was using https://github.com/P3GLEG/tauri-plugin-mcp. Without that, Claude Code just tries things blindly and they work or not.

Re: Electron vs. Tauri

#49

Post by pornel »

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

Last time I messed with Tauri my bin folder in my code/building directory ballooned to 10 gigs. If the final product is “lightweight” the development process surely is not.

Cargo's cache is ridiculously massive (half of which is debug info: zero-cost abstractions have full-cost debug metadata), but you can delete it after building.

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.

Re: Electron vs. Tauri

#50

Post by Fizzadar »

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…

In my experience building Kanmail neither Tauri or Wails have this figured out. I had to combine elements of both projects custom linuxdeploy GTK plugin and I’m still not 100% sure it works everywhere. https://github.com/Oxygem/Kanmail/blob/19c5bfe78fe1b22147c01...
Post reply on HN