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

61–70 of 85 posts

Re: Electron vs. Tauri

#61

Post by max-privatevoid »

WhyNotHugo wrote: post #15
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.

The idea is awful as well if you spend one second thinking about dependency sharing.

Re: Electron vs. Tauri

#62

Post by codelikeawolf »

lone-cloud wrote: post #31

- "Electron comes with a few rather significant drawbacks" Not going to mention them at all though? - what possible reason could one have to use Next with Electron? Not everything needs to be in Next and there's no reason for SSR + Node.js API server (primary advantages of Next vs React) when the client and server are on the same machine. The author's solution is to wrap this with another dubious framework (Nextron l…

Yeah, it makes zero sense to use a SSR framework for an Electron app. Just use React, Vue, or Svelte directly. It's one of the few use cases where a SPA makes sense, since the bundle is being served locally.

Re: Electron vs. Tauri

#64

Post by Arrowmaster »

WhyNotHugo wrote: post #15
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.

AppImages are supposed to be able to handle all of that and I have used a number of them that do. In the case of Tauri though it seems nobody on the framework team knows Linux well enough to fix the build process to not constantly break as libraries update on the GitHub Ubuntu VMs or to make all the required dynamically linked libraries get included in the AppImage. And finally most of the downstream app developers have never written an app for Linux and chose the framework expecting it to solve the problems it clearly isn't.

Re: Electron vs. Tauri

#65

Post by Arrowmaster »

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

Sadly, every time that one guy posts his personal finance app on HN I try it and every time tauri gives me trouble to build, and when I fix whatever build errors it gives me it basically opens up a blank window and the app doesn't work (He now offers a Docker image which I can't help but feel is related to these difficulties).

I think the blank window bug was caused by a change in the libraries used by the webview on Ubuntu 22.04 used by suggested build action. Details and fixes were spread across bug reports in multiple downstream projects but afaik it was fixed in an Ubuntu update.

Re: Electron vs. Tauri

#66

Post by xigoi »

pornel wrote: post #49
galleywest200 wrote: post #7

Earlier quoted context omitted.

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.

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

If it’s just logs, I would prefer to redirect it to /dev/null.

Re: Electron vs. Tauri

#67

Post by xigoi »

aabhay wrote: post #8
galleywest200 wrote: post #7

Earlier quoted context omitted.

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.

That’s just Rust in general. But what you lose in disk space you gain considerably in optimized executables. The tradeoff is well worth it.

There is no tradeoff. The bloat of Rust is caused by its NPM-style ecosystem where everything has 1000 dependencies, which is completely orthogonal to performance.

Re: Electron vs. Tauri

#68

Post by c-hendricks »

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…

I've ditched the AppImage build in my tauri apps for .deb. They work fine on other distros as long as you install libwebkitgtk

Re: Electron vs. Tauri

#69

Post by c-hendricks »

haideralshamma wrote: post #23

I am building an open source desktop app in Tauri [1]. One of the issues I encountered was having to duplicate and sync types between the TypeScript frontend and Rust. On the other hand, Rust proved to be a great language with a sizeable ecosystem for building application backends. [1]: https://github.com/haideralsh/prompt-lab

I settled on graphql, that generates my types for both Rust and TypeScript.

Re: Electron vs. Tauri

#70

Post by hysan »

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 target, they don’t recommend Tauri: https://github.com/tauri-apps/wry/issues/1064#issuecomment-2...

The upstream projects aren’t in a place to support this yet so this feature didn’t make it into Tauri v2. I’ve been tracking this for a long time and hope that they will make it possible in v3.

Post reply on HN