5 ms·

Electron vs. Tauri

133 points by birdculture 11mo ago

aabhay 11mo ago
If they didn’t have the nodejs dependency then the Tauri bundle could be as small as 20mb. Another pro not mentioned is that native integrations (i.e. obj-c on macos) are much easier to do since rust has great ffi integration with other native libraries. The biggest pro to electron is that it has extensive plugins that are often widely used in production by large companies. But Tauri is definitely winning and any new project should use Tauri no matter what essentially.
dfabulich 11mo ago
> Lack of support for .appx and .msix bundles on Windows https://github.com/tauri-apps/tauri/issues/4818 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't ready for primetime on Windows.
- 01HNNWZ0MV43FF 11mo ago
  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.
  - TingPing 11mo ago
    Yes it should be doable manually, not like this is a complex feature.
  - ptx 11mo ago
    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/launch/web-to-app-linking https://learn.microsoft.com/en-us/windows/apps/develop/launc...
sundarurfriend 11mo ago
> 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 Electron), I have to constantly remember to close the app at the soonest possible point in time, or I can tangibly feel the sluggishness it creates in the system performance. So if there's a native choice and a Tauri-written choice, I'd heavily prefer the native choice nowadays, even at the cost of some features.
- quinncom 11mo ago
  I'm curious what the impact on system resources is between a Tauri-based app versus the web app version opened in a browser window. If the features for both are the same, I imagine the resource utilization is also the same. The only exception might be that browsers such as Chrome will force inactive tabs to sleep. Readwise Reader is one app I've compared both versions to, and I don't see much difference in resource usage for either version.
- galleywest200 11mo ago
  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.
  - aabhay 11mo ago
    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.
    - xigoi 11mo ago
      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.
kristianp 11mo ago
How does Wails compare here? I'm guessing it's less mature than Tauri.
- TACIXAT 11mo ago
  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-comparison https://github.com/Elanis/web-to-desktop-framework-compariso...
anon115 11mo ago
i had a better time vibe coding with gpt 4 with WAILS> vs any of these Electron> Tauri
- pylotlight 11mo ago
  Go is likely much easier to work with here than the other platforms imo
- undeveloper 11mo ago
  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
Arrowmaster 11mo ago
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.
- WhyNotHugo 11mo ago
  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.
  - max-privatevoid 11mo ago
    The idea is awful as well if you spend one second thinking about dependency sharing.
  - Arrowmaster 11mo ago
    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.
- dfabulich 11mo ago
  It's like they always say: Win32 is the only stable ABI on Linux.
  - dijit 11mo ago
WhyNotHugo 11mo ago
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.
mootoday 11mo ago
My personal favorite to keep an eye on is https://www.gpui.rs/ 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!
- brainless 11mo ago
  This was recently on HN and I think it adds so much value to GPUI: https://github.com/longbridge/gpui-component/ https://github.com/longbridge/gpui-component/
- aitchnyu 11mo ago
  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.
- lelanthran 11mo ago
  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.
haideralshamma 11mo ago
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 https://github.com/haideralsh/prompt-lab
- bpev 11mo ago
  fwiw, I think the most comprehensive cross-typing work done here has been specta: https://github.com/specta-rs/tauri-specta https://github.com/specta-rs/tauri-specta
  - sipjca 11mo ago
    yes, it works, I would recommend it even if it's a bit awkward at times
- c-hendricks 11mo ago
  I settled on graphql, that generates my types for both Rust and TypeScript.
auggierose 11mo ago
Of course a lot of apps will not be able to live with the restrictions, but if you can write your app as a webapp (PWA), you should do that instead of using Electron or Tauri. I do it because I find either build system atrocious, and with webapps I can just use esbuild. Using Chrome for example, people can install webapps as desktop apps on any operating system, if they like, and the footprint is minimal.
testdelacc1 11mo ago
> Tauri doesn’t seem to be able to create Mac universal binaries from their arm64 and x64 subcomponents. I think this problem will be “solved” on its own. According to the October Steam hardware survey, about 15% of macs are still on Intel, with the number dropping each month. In a year it’ll be less than 10%. The software side isn’t looking good either - Intel Macs have received their last OS update this year. In 2028 Apple will classify Intel Macs as “vintage”, ending most service and parts support. I’m not making a judgement here on Apple’s decisions. But Tauri is unlikely to spend their time optimising for a small fraction (Intel) of a small fraction (mac users), which is also reducing over time. Their time is probably better spent getting Windows support up to scratch because Windows isn’t going anywhere.
pjmlp 11mo ago
What about neither? If it must be Web, run the application headless and launch the system browser. But really if 50 year olds can jungle between native and Web, so do you.
iamsaitam 11mo ago
"Compatibility issues across system webviews are exceedingly rare, especially for the major operating systems." When it comes to CSS, there will be the same vendor issues that you have on websites. It's not a magic bullet.
lone-cloud 11mo ago
- "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.
- otikik 11mo ago
  They do mention bloat and memory usage
- codelikeawolf 11mo ago
  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.
ifh-hn 11mo ago
Would love to see these in comparison to desktop flutter.
deleted 11mo ago
[deleted]
dangoodmanUT 11mo ago
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.
stared 11mo ago
As right now I try using Tauri 2 (work very much in progress, https://github.com/stared/rusted-doom-launcher 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 https://github.com/P3GLEG/tauri-plugin-mcp. Without that, Claude Code just tries things blindly and they work or not.
anaisbetts 11mo ago
Tauri's approach of using the system Webview just doesn't scale to millions of users. You will end up having to tell your customers, "In order to fix the bugs in our app, you need to install a new version of your OS", or in the case of Apple, sometimes even saying, "You need to buy a new computer to use our app". It's not a great conversation to have. Philosophically, it also optimizes something that doesn't really matter much in 2025, download and disk space - despite the perceptions, the system Webview usually uses the same order of magnitude memory as Electron; maybe a little less, but not a Lot less. We can see the WhatsApp rewrite on Windows to use WebView2 as evidence of that. The one time that Tauri is legitimately better though, is if you've got a lot of Rust code that you want to integrate - GitButler for example uses Tauri and it works for them because they have a lot of Git systems code and it's all in Rust.
- PinkFluffyLlama 11mo ago
  We (GitButler) however keep running into packaging issues that make all but a very small handful of linux distros "usable". There are also numerous papercuts that we keep getting due to Tauri being comparably less mature. We've been making steps towards moving away from Tauri. We now already have the capability to run our rust backend as a web-server and use the frontend in a regular browser. One of the next steps is to package the frontend into an electron app, and run the web-server as a sidecar process. While there may be size downsides to packaging an entire browser - size isn't really a big issue compared to the program simply not working on a large user demographic.
phaser 11mo ago
I seem to be the only one with some degree of success with Tauri :) After someone suggested here in HN I switched Microlandia[1] from deno-webview[2] to Tauri. So far, it’s been a pretty good experience in Windows and macOS, of all the bug reports I received, zero are related to Tauri. Only one caveat: For Steam Linux, I had to package the game in electron after spending an entire weekend in library hell trying to get it to work in the Steamworks sniper SDK. 1. https://explodi.itch.io/microlandia https://explodi.itch.io/microlandia 2. https://github.com/webview/webview_deno https://github.com/webview/webview_deno
- sipjca 11mo ago
  I've also had some degree of success with Tauri but not without pains. But to be fair most of the pains have come from the state of Linux DE (it's absolute hell if you ask me) For the most part, things just work on MacOS (Windows I don't use much, but I don't get that many bug reports from Windows, so it must work alright. I would guess I have 50k Windows users?). I don't have any experience with Electron, but in many ways I assume it probably is much more robust of an experience than Tauri. A lot of stuff has felt shaky to me, yet it does work. It's just not always a confidence inspiring experience. But again, maybe this is just the state of cross platform experiences generally? I don't know because I don't have enough experience to say Source, I'm the author of: http://github.com/cjpais/Handy http://github.com/cjpais/Handy
schmorptron 11mo ago
What is the implementation difference between using the system WebView (fragmented, especially bad under linux) and using one shared tauri-base runtime that only gets breaking changes updates every 2 years or so so there aren't twenty different ones running at the same time and it ends up like electron? Would bundling one extended support release of chromium or firefox's backends that are then shared between all tauri apps not suffice?
helf 11mo ago
[dead]
yumraj 11mo ago
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.
Fire-Dragon-DoL 11mo ago
Would it be possible to have electron as an OS package (so, updated) and Tauri use such package on Linux? What are the technical limitations for this? I honestly know very little about webviews on linux.
zvr 11mo ago
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.
niutech 11mo ago
There are even more lightweight alternatives for Electron than Tauri: NodeGui, Neutralino.js, Sciter, DeskGap and more: https://github.com/sudhakar3697/awesome-electron-alternatives https://github.com/sudhakar3697/awesome-electron-alternative...

133 points by birdculture 11mo ago

aabhay 11mo ago

If they didn’t have the nodejs dependency then the Tauri bundle could be as small as 20mb. Another pro not mentioned is that native integrations (i.e. obj-c on macos) are much easier to do since rust has great ffi integration with other native libraries. The biggest pro to electron is that it has extensive plugins that are often widely used in production by large companies. But Tauri is definitely winning and any new project should use Tauri no matter what essentially.

dfabulich 11mo ago

> Lack of support for .appx and .msix bundles on Windows https://github.com/tauri-apps/tauri/issues/4818 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't ready for primetime on Windows.

01HNNWZ0MV43FF 11mo ago
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.
- TingPing 11mo ago
  Yes it should be doable manually, not like this is a complex feature.
- ptx 11mo ago
  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/launch/web-to-app-linking https://learn.microsoft.com/en-us/windows/apps/develop/launc...

sundarurfriend 11mo ago

> 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 Electron), I have to constantly remember to close the app at the soonest possible point in time, or I can tangibly feel the sluggishness it creates in the system performance. So if there's a native choice and a Tauri-written choice, I'd heavily prefer the native choice nowadays, even at the cost of some features.

quinncom 11mo ago
I'm curious what the impact on system resources is between a Tauri-based app versus the web app version opened in a browser window. If the features for both are the same, I imagine the resource utilization is also the same. The only exception might be that browsers such as Chrome will force inactive tabs to sleep. Readwise Reader is one app I've compared both versions to, and I don't see much difference in resource usage for either version.
galleywest200 11mo ago
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.
- aabhay 11mo ago
  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.
  - xigoi 11mo ago
    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.

kristianp 11mo ago

How does Wails compare here? I'm guessing it's less mature than Tauri.

TACIXAT 11mo ago
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-comparison https://github.com/Elanis/web-to-desktop-framework-compariso...

anon115 11mo ago

i had a better time vibe coding with gpt 4 with WAILS> vs any of these Electron> Tauri

pylotlight 11mo ago
Go is likely much easier to work with here than the other platforms imo
undeveloper 11mo ago
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

Arrowmaster 11mo ago

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.

WhyNotHugo 11mo ago
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.
- max-privatevoid 11mo ago
  The idea is awful as well if you spend one second thinking about dependency sharing.
- Arrowmaster 11mo ago
  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.
dfabulich 11mo ago
It's like they always say: Win32 is the only stable ABI on Linux.
- dijit 11mo ago

WhyNotHugo 11mo ago

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.

mootoday 11mo ago

My personal favorite to keep an eye on is https://www.gpui.rs/ 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!

brainless 11mo ago
This was recently on HN and I think it adds so much value to GPUI: https://github.com/longbridge/gpui-component/ https://github.com/longbridge/gpui-component/
aitchnyu 11mo ago
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.
lelanthran 11mo ago
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.

haideralshamma 11mo ago

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 https://github.com/haideralsh/prompt-lab

bpev 11mo ago
fwiw, I think the most comprehensive cross-typing work done here has been specta: https://github.com/specta-rs/tauri-specta https://github.com/specta-rs/tauri-specta
- sipjca 11mo ago
  yes, it works, I would recommend it even if it's a bit awkward at times
c-hendricks 11mo ago
I settled on graphql, that generates my types for both Rust and TypeScript.

auggierose 11mo ago

Of course a lot of apps will not be able to live with the restrictions, but if you can write your app as a webapp (PWA), you should do that instead of using Electron or Tauri. I do it because I find either build system atrocious, and with webapps I can just use esbuild. Using Chrome for example, people can install webapps as desktop apps on any operating system, if they like, and the footprint is minimal.

testdelacc1 11mo ago

> Tauri doesn’t seem to be able to create Mac universal binaries from their arm64 and x64 subcomponents. I think this problem will be “solved” on its own. According to the October Steam hardware survey, about 15% of macs are still on Intel, with the number dropping each month. In a year it’ll be less than 10%. The software side isn’t looking good either - Intel Macs have received their last OS update this year. In 2028 Apple will classify Intel Macs as “vintage”, ending most service and parts support. I’m not making a judgement here on Apple’s decisions. But Tauri is unlikely to spend their time optimising for a small fraction (Intel) of a small fraction (mac users), which is also reducing over time. Their time is probably better spent getting Windows support up to scratch because Windows isn’t going anywhere.

pjmlp 11mo ago

What about neither? If it must be Web, run the application headless and launch the system browser. But really if 50 year olds can jungle between native and Web, so do you.

iamsaitam 11mo ago

"Compatibility issues across system webviews are exceedingly rare, especially for the major operating systems." When it comes to CSS, there will be the same vendor issues that you have on websites. It's not a magic bullet.

lone-cloud 11mo ago

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

otikik 11mo ago
They do mention bloat and memory usage
codelikeawolf 11mo ago
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.

ifh-hn 11mo ago

Would love to see these in comparison to desktop flutter.

deleted 11mo ago

[deleted]

dangoodmanUT 11mo ago

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.

stared 11mo ago

As right now I try using Tauri 2 (work very much in progress, https://github.com/stared/rusted-doom-launcher 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 https://github.com/P3GLEG/tauri-plugin-mcp. Without that, Claude Code just tries things blindly and they work or not.

anaisbetts 11mo ago

Tauri's approach of using the system Webview just doesn't scale to millions of users. You will end up having to tell your customers, "In order to fix the bugs in our app, you need to install a new version of your OS", or in the case of Apple, sometimes even saying, "You need to buy a new computer to use our app". It's not a great conversation to have. Philosophically, it also optimizes something that doesn't really matter much in 2025, download and disk space - despite the perceptions, the system Webview usually uses the same order of magnitude memory as Electron; maybe a little less, but not a Lot less. We can see the WhatsApp rewrite on Windows to use WebView2 as evidence of that. The one time that Tauri is legitimately better though, is if you've got a lot of Rust code that you want to integrate - GitButler for example uses Tauri and it works for them because they have a lot of Git systems code and it's all in Rust.

PinkFluffyLlama 11mo ago
We (GitButler) however keep running into packaging issues that make all but a very small handful of linux distros "usable". There are also numerous papercuts that we keep getting due to Tauri being comparably less mature. We've been making steps towards moving away from Tauri. We now already have the capability to run our rust backend as a web-server and use the frontend in a regular browser. One of the next steps is to package the frontend into an electron app, and run the web-server as a sidecar process. While there may be size downsides to packaging an entire browser - size isn't really a big issue compared to the program simply not working on a large user demographic.

phaser 11mo ago

I seem to be the only one with some degree of success with Tauri :) After someone suggested here in HN I switched Microlandia[1] from deno-webview[2] to Tauri. So far, it’s been a pretty good experience in Windows and macOS, of all the bug reports I received, zero are related to Tauri. Only one caveat: For Steam Linux, I had to package the game in electron after spending an entire weekend in library hell trying to get it to work in the Steamworks sniper SDK. 1. https://explodi.itch.io/microlandia https://explodi.itch.io/microlandia 2. https://github.com/webview/webview_deno https://github.com/webview/webview_deno

sipjca 11mo ago
I've also had some degree of success with Tauri but not without pains. But to be fair most of the pains have come from the state of Linux DE (it's absolute hell if you ask me) For the most part, things just work on MacOS (Windows I don't use much, but I don't get that many bug reports from Windows, so it must work alright. I would guess I have 50k Windows users?). I don't have any experience with Electron, but in many ways I assume it probably is much more robust of an experience than Tauri. A lot of stuff has felt shaky to me, yet it does work. It's just not always a confidence inspiring experience. But again, maybe this is just the state of cross platform experiences generally? I don't know because I don't have enough experience to say Source, I'm the author of: http://github.com/cjpais/Handy http://github.com/cjpais/Handy

schmorptron 11mo ago

What is the implementation difference between using the system WebView (fragmented, especially bad under linux) and using one shared tauri-base runtime that only gets breaking changes updates every 2 years or so so there aren't twenty different ones running at the same time and it ends up like electron? Would bundling one extended support release of chromium or firefox's backends that are then shared between all tauri apps not suffice?

helf 11mo ago

[dead]

yumraj 11mo ago

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.

Fire-Dragon-DoL 11mo ago

Would it be possible to have electron as an OS package (so, updated) and Tauri use such package on Linux? What are the technical limitations for this? I honestly know very little about webviews on linux.

zvr 11mo ago

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.

niutech 11mo ago

There are even more lightweight alternatives for Electron than Tauri: NodeGui, Neutralino.js, Sciter, DeskGap and more: https://github.com/sudhakar3697/awesome-electron-alternatives https://github.com/sudhakar3697/awesome-electron-alternative...