- "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 looks abandoned and hasn't been updated for over 10 months btw) to force them to somehow work together. Like why?
- the idea behind Tauri to leverage the user's system's webview may sound like free real estate, but as many Cordova devs have previously found out, it's incredibly risky when you have no control of your own runtime. Desktop webviews are not a uniform layer. Ex. Webrtc is not supported on Linux webviews.
Electron vs. Tauri
31–40 of 85 posts
Re: Electron vs. Tauri
#32The 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.
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.
Re: Electron vs. Tauri
#33i had a better time vibe coding with gpt 4 with WAILS> vs any of these Electron> Tauri
simply due to the fact that less rust code exists than JS / TS or go, these languages are just less popular (and frankly, require less code written with the easy of abstraction they have
Re: Electron vs. Tauri
#34Would love to see these in comparison to desktop flutter.
Re: Electron vs. Tauri
#35The 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…
Recently I tried Electron app, it didn't work out of the box in Ubuntu 24.04 (AppImage). Turned out some issue with apparmor. It worked if extracted manually, though, but that's a bit of friction for ordinary users, also probably wouldn't work with updater.
I think that's the issue: https://github.com/electron/electron/issues/41066
Not even sure who to blame in this situation.
Re: Electron vs. Tauri
#36My 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!
I installed Zed to read JSON logs that caused my browser and Pycharm (Jetbrains, Java-based) to lag hard. Sometimes I scroll down to the millionth line since the quickness makes me think I downloaded only a subset.
Re: Electron vs. Tauri
#37- "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…
They do mention bloat and memory usage
Re: Electron vs. Tauri
#38> 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.
Speaking of URI handlers, any idea what this bit in Microsoft's docs is supposed to mean?
> Starting with the Windows 10 Creators update and in all Windows 11 versions, supported links clicked in Microsoft Edge Legacy will launch the corresponding app. Supported links clicked in supported browsers (for example, Microsoft Edge Chromium, Firefox, Internet Explorer, etc.), will keep you in the browsing experience.
I can think of two ways to interpret it, neither of which seems good:
1) It doesn't work at all in any modern browser, and "supported" is the term Microsoft has chosen to describe this state of affairs?
2) Microsoft is sneakily installing a Firefox extension to subvert URL handling and embed UWP apps inside Firefox ("the browsing experience")?
[1] https://learn.microsoft.com/en-us/windows/apps/develop/launc...
Re: Electron vs. Tauri
#39The 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…
Using `zig-cc (clang)` to set a particular `LibC` version is one of the best decisions i have made, and saved me from those meaningless libC mismatch errors!
Re: Electron vs. Tauri
#40Earlier 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.
It is not surprising that a libc headed by the chief gnuissance would produce sn ecosystem where everything works better when apps are compiled from source for each distro.