Tauri vs. Electron – Real world application

https://www.levminer.com/blog/tauri-vs-electron

by Levminer • 4 years ago

215 104 4 years ago

levminer.com

Levminer4• 4 years ago

Comparing Electron and Tauri - With a real world app

piratey• 4 years ago

Using Tauri for my most recent project, I have to say the Development experience was phenomenal.

Only downside that the article rightly points out us the knowledge of Rust, which was new to me.

Also Tauri has Android & iOS targets on its roadmap too.

MuffinFlavored• 4 years ago

What were your first impressions of Rust?

thegeekpirate• 4 years ago

There's also https://wails.io, which uses Go instead of Rust.

vindarel• 4 years ago

and https://neutralino.js.org/

Their exciting part is

You can extend Neutralinojs with any programming language (via extensions IPC) and use Neutralinojs as a part of any source file (via child processes IPC).

still:

Neutralinojs doesn't bundle Chromium and uses the existing web browser library in the operating system (Eg: gtk-webkit2 on Linux). Neutralinojs implements a WebSocket connection for native operations and embeds a static web server to serve the web content.

Comparison with Electron, Tauri and more: https://github.com/Elanis/web-to-desktop-framework-compariso...

animesh• 4 years ago

You can extend Neutralinojs with any programming language (via extensions IPC) and use Neutralinojs as a part of any source file (via child processes IPC).

I do not understand the second part of this sentence. What does it mean to use Neutralinojs as a part of any source file (via child processes IPC)?

pkulak• 4 years ago

And if your user has the correct runtime for the webview used by Tauri you can just send them a single executable

So does this mean all these comparisons are between a web bundle that runs on an existing VM, and a web bundledthat came packaged with a VM? Because I thought the whole point of Electron was that all the dependencies came packaged together, even if that adds 100 megs to the install.

esprehn• 4 years ago

Yup. Tauri is more like Ionic or Cordova than Electron. You get a mostly web based developer experience, but without the browser matrix simplification so you're still at the whim of the system WebView capabilities for the view layer.

The good news is the built in webviews have come a long way since webcompat is much better across browsers, but it's still extra things to worry about and can produce problems on old MacOS or Windows pre-11.

https://tauri.app/v1/api/js/

chippers• 4 years ago

disclaimer: contributor to Tauri

This ends up often being my main contention with Rust, when making useful programs it often leads to large compile times mostly due to the linker. The mold linker can help greatly, but it's still not a great developer experience. Something I want to create in the future is a fully compiled Tauri application except it takes the webview sources at runtime, allowing a fast-as-possible development reload as long as you are only touching the frontend application and not the Rust side. On the Rust side there are a few options, one of them being developing something like WASM plugins on the backend where their individual dependencies are much less than a full application.

jtolmar• 4 years ago

The page is doing something strange on scroll, it's almost unbearable on Firefox mobile

yajjackson• 4 years ago

I noticed the same, could not figure out the cause.

Levminer4• 4 years ago

Thanks for pointing it out, I fixed it. I was using background-blur in CSS, Firefox mobile didn't like it I guess.

api3• 4 years ago

One thing I don't see mentioned is the horror of shipping for Windows. You'll need Windows to have the Edge runtime, which means you have to bundle it or install it as an add-on. People will complain about this, especially IT people, because Edge runtime runs some kind of stupid background service all the time for no clear reason. It's also brittle since you will have to constantly keep your installer up to date with new releases of the Edge runtime or use a fragile MS URL that could stop working at any time and that won't work behind some firewalls.

TL;DR: trying to use the native web view on Windows is horrible because there is no native web view and MS can't bundle software for their own platform.

Of course I suppose shipping any software for Windows is horrible...

easton• 4 years ago

It doesn't help for most corporate environments (at least, not yet), but Windows 11 ships with the Edge WebView2 Runtime. They are "evaluating" shipping it via Windows Update to Windows 10 machines that are domain-joined: https://blogs.windows.com/msedgedev/2022/06/27/delivering-th...

Levminer4• 4 years ago

You are a little behind. Edge webview is included in Windows 11 by default. On Windows 10 the installer downloads it automatically. You don't have to do anything.

api3• 4 years ago

Does it work on Windows 10 Enterprise running Crowdstrike in the EU during a full moon on an odd numbered day while it's raining?

Being sarcastic of course, but... hey maybe I'll take another look.

dfabulich• 4 years ago

Tauri has options to take care of that.

Microsoft's WebView2 has three distribution options: the "evergreen bootstrapper," the "evengreen standalone installer," and "fixed version" (where you embed a browser version in your installer).

https://developer.microsoft.com/en-us/microsoft-edge/webview...

Tauri supports all three of those mechanisms. If you choose to embed the browser directly in your installer, it adds 100MB+ to your installer size, but it's guaranteed to work anywhere. (They even support Windows 7.)

https://tauri.app/v1/guides/building/windows#webview2-instal...

ripley122• 4 years ago

Man, there are a lot of incorrect statements in this.

MS keeps the evergreen bootstrapper URL stable specifically so you can download it programmatically, it’s not fragile. And if you choose to ship the evergreen bootstrapper yourself, you don’t have to update it.

The WebView2 runtime ships with Windows 11, major applications like Office, and they’re currently rolling it out to most Windows 10 installs.

api3• 4 years ago

The problem is enterprise environments where they tend to run stripped down locked down Windows installations and don't like to upgrade.

We used to use a native webview in an app and found that our app (packaged as MSI) would not install in a lot of enterprise environments because they don't allow secondary installers not signed by the same key as the primary installer. That means no bundling or side loading Edge. They would also require special security policy review to install Edge, making the whole thing really painful.

If you are only targeting personal end users a lot of what I said may not apply but it absolutely does apply in enterprise.

P.S. We did finally drop Windows 7 support a while back but we still get asked for it regularly. We get asked for Windows XP every now and then. Enterprise.

chimen• 4 years ago

Flutter desktop? Anyone tried it?

gbro3n• 4 years ago

Flutter is really compelling, would love to be given a project using it based on what I've seen of the environment and tooling. Dart is nice too. In my recent evaluation though I decided to go with PWAs unless I really need native only APIs. Modern web APIs are decreasing the argument for native.

lobstrosity420• 4 years ago

There is also Ionic if you need an extra push on what the Web APIs can do.

mojzu• 4 years ago

I did a short evaluation a while back (while support for desktop/web was still in beta so much has probably changed), ended up going the PWA route. Developer experience was fantastic, code completion/debugging/documentation/compiling were all great and smooth experiences, Dart was easy to pick up quickly although some of the code generation stuff such as serialisation/deserialisation was a bit clunky. However the deciding factor at the time was that the end result felt very much like a mobile app forced into a desktop environment, things that users expected to have like copy+paste weren't there, keyboard shortcuts that users took for granted were a hassle to reimplement, the scrolling felt 'off' in a desktop environment and performance wise it could feel stuttery quite often.

I quite like the fundamental ideas behind Flutter (a lightweight GUI runtime that can produce consistent results across many platforms) so hoping these are already or on their way to being ironed out

PhantomBKB• 4 years ago

Yes, it's excellent.

orthecreedence4• 4 years ago

I've evaluated both Tauri and Flutter + flutter_rust_bridge.

I immediately felt really productive in Tauri/Svelte/rust. It just kind of clicked with me (completely new to Svelte, but been doing SPAs and JS desktop apps for some time as well as being in the rust scene for years). It was like the ease of electron, but with a better build framework for bundling rust. Really a good setup, easy to get into, easy and fast to build in.

I think Flutter is a really great UI framework. The way it's set up really makes sense and makes it fairly easy to structure the UI. That said, I really do not like Dart at all. I found it difficult to learn a new language and a new UI framework at the same time, and found myself pining for HTML/javascript again. flutter_rust_bridge obviously alleviated this a bit because it made it possible to move most of the logic into rust. I am honestly also worried about Flutter being a Google project. They tend to abandon projects quite a bit. I do like the promises of Flutter and didn't actually have any material issues with it. I think I might give it another go on the next app I build and see if I can get over the Dart hump.

vivekin• 4 years ago

I have been using Tauri to develop a Kubernetes IDE: https://github.com/nirops/yakiapp

One additional thing from my experience, is if using Rust as a backend, the turnaround time for hot loading Rust changes is not trivial. This leads to longer times in building things vis-a-vis building in Electron with .ts/.js backend.

Levminer4• 4 years ago

Yes, good point you need a very good processor for instant hot reload.

saidinesh52• 4 years ago

Mold linker cut down a lot of the build time when we were writing a tauri app, but the build times were still .. not my favorite.

orthecreedence4• 4 years ago

I know there's probably docs somewhere, but what was the process to integrate mold into your build chain? Is it involved or fairly easy? I just heard of this for the first time and wondering if it could be useful to cut down build times in all my rust libs/apps...

EDIT: found this: https://www.reddit.com/r/rust/comments/rhcnzt/mold_a_modern_...

keraf• 4 years ago

The 5th point in this article is what makes me end up using Electron most of the time.

As much as I love Tauri (and Wails), WebView requires to make sure the application renders exactly the same across all platforms. Sure, Electron comes with its downsides like the article rightfully points out. But having a UI that renders and behaves exactly the same on all platforms (thanks to the version locked Chromium bundled in the app) is really nice to have.

I wish there would be the possibility to bundle a renderer (maybe a more lightweight one?) with Tauri or Wails instead of using WebView.

cageface• 4 years ago

I recently chose Electron over Tauri for the same reasons. Tauri would be a better fit for my app in some respects but it's a music player and Safari doesn't support all the audio formats I care about.

https://github.com/milesegan/minimoon

kitsunesoba• 4 years ago

The downside of that control though is an application that's arguably a little too specifically targeted — it's understandable wanting to target the same engine but if your app breaks with different but reasonably recent versions of chromium I would say it's too brittle.

It also widens attack vectors considerably when your entire userbase is all on the same probably-outdated build of electron-bundled chromium.

Klonoar• 4 years ago

System webviews on macOS aren’t updated after a certain point, so Tauri is not necessarily always a win re: your final point.

BiteCode_dev• 4 years ago

If you only provide a desktop app yes.

If you also provide a web app, then the work needs to be done anyway.

Kye• 4 years ago

Someone somewhere has already figured out how to run Electron through WASM.

pornel3• 4 years ago

Is that really such a big deal?

Browser engines these days aren't so bad, especially if all you need from them is basic CSS for the UI. You still have a fully-fledged native language underneath it, so you're not limited to what Web APIs can do.

jahewson• 4 years ago

There is no such thing as “basic CSS”. Of all things it’s the most wildly moving target I’ve ever encountered.

autoconfig• 4 years ago

Same here. Depending on the type of application being built, this can be a huge downside. E.g., if you want to store data locally using IndexedDB getting it to work properly on Safari (and to some extent Firefox) can be a soul destroying experience. See here for some examples: https://gist.github.com/pesterhazy/4de96193af89a6dd5ce682ce2...

Unless I'm building an app that also needs to work on the web, I'm choosing Electron.

alexvoda• 4 years ago

And here you have proof for part of the reason Chrome dominates the web now.

No matter the values and benefits, testing on another browser is to much of a hassle for most web devs.

WhyNotHugo2• 4 years ago

As much as I love Tauri (and Wails), WebView requires to make sure the application renders exactly the same across all platforms.

I think having an alternative to the Google-centric monoculture that is Chromium is actually one of Tauri's big points.

cheriot2• 4 years ago

You have to rewrite your app's backend in Rust

Tauri has "Other Bindings" on the roadmap, but, for now, this requirement is big limitation. imo, the article should have lead with that instead of burying it at #4.

sysop073• 4 years ago

It's only a limitation if your app is currently written in Javascript, which seems like a silly assumption. If your app is currently written in Rust, Electron has the equally big downside of "you have to rewrite your app's backend in Javascript"

cheriot2• 4 years ago

My impression is that Electron can wrap whatever backend you want to use. Is that not the case?

parker-codes• 4 years ago

Regarding point #4, I think the clear winner is Tauri. I'll clarify --

While writing in Node is great if you don't know Rust, your users are being shipped an entire Node runtime, which has size, memory, and security issues. So in this case Electron has a "better" DX completely at the cost of the user.

Tauri has JS/TS APIs, but if you need to do extensive backend work then it requires some learning at the benefit of your users. After learning Rust myself, I'd say it's the benefit of the developers too, but that's just my opinion. :)

hasperdi• 4 years ago

You're implying that application written in Rust would not have no size, memory and security issues. That is of course not true.

maleldil• 4 years ago

Do you think it's unreasonable to assume that an app written in Rust will be smaller, use less memory and be safer than a similar app written in JavaScript?

datagram• 4 years ago

As far as size goes:

a) Compiled JS apps generally have to include a whole Javascript engine, which makes them significantly larger b) Rust is designed for shipping small static binaries, whereas Node is not; node.exe by itself is tens of megabytes, and you can only make it smaller by compiling it yourself from source. Deno has compiling static binaries as an explicit feature so it may fare better in the long run, but it's still limited by a)

As an example: I just tested on MacOS and a hello world program compiled with `rustc` is 378KB, whereas one built with `deno compile` is 74MB.

hs86• 4 years ago

Those RAM usage comparisons should consider the shared memory among those processes. Aren't those renderer and zygote processes forks of each other?

I don't think that tools like htop or Process Explorer give us an easy at-a-glance answer to how much RAM multi-process browsers or Electron apps need. My current approach is to monitor the currently free RAM while at the same time closing the entire application. That delta at that moment is a more accurate representation of the app's memory consumption than summing up RSS values or working sets.

miniBill• 4 years ago

Those are shared but... Tauri is using less than 80 megs, Electron is using 143 for the main process alone, so it doesn't really make a difference. Tauri is way lighter

synergy202• 4 years ago

assuming you use chrome, electron will reuse the chromium libraries, so the net increase on memory is not that large. with Tauri, it will have to spin a new set of (memory hungry) browser libraries(i.e. libwebkit2gtk on linux, similar stuff on Mac and Windows) that are all new memory usage on top of chrome(nothing to share), not to mention the libraries Tauri uses are not as "modern" as Chromium on html5/css/js/webapi support.

I still feel Electron is the best approach now.

jyap• 4 years ago

Just a correction to OP since I noticed it twice.

Used of “exited” (to exit) when you mean “excited” (to be excited).

typon• 4 years ago

Calling this a "real world application" is a big stretch imo...Javascript's problems really come to the forefront when implementing complex logic in the backend - Rust's excellent type system helps a lot with that.

However, if you have an app that has a lot of interactivity, using the web_sys API is a huge pain that basically caused me to end development on my side project. Working with DOM APIs in Javascript is so much easier than working with them in Rust.

orthecreedence4• 4 years ago

I'm in a sweet spot for something like Tauri: I have an app that does a lot of cryptography and dealing with binary data in browserland is horrible. Embedding rust and leaning on it for the business logic and crypto stuff while only relegating the UI to html/javascript has been a huge success for me.

I think the rust frontend ecosystem has a long way to go before it can really compete with javascript and the many existing frontend frameworks.

jupp0r4• 4 years ago

"The app is compiled to a binary, which means you have to be an expert at reverse engineering to be able to de-compile the app."

It just means that nobody has written automated tooling to do this. The procedure is super easy and the implication that there is any security benefit to the way Tauri bundling works is fundamentally flawed.

intelVISA• 4 years ago

To be fair it's hard to understand what a "jump not equal" does if the numbers on FizzBuzz are accurate.

junon• 4 years ago

I agree with your last point, no, sorry, reverse engineering machine code back to actual, re-compilable source is not at all straightforward. Hex-rays has been trying to do this for ages and still doesn't get things right

yencabulator• 4 years ago

With Tauri, the backend with all the non-UI logic is Rust, so you can't just magically spit out source code from the binary. With Electron, the non-UI logic is NodeJS, so you can extract bundled Javascript. Bundled Javascript is much more obvious than machine code.

jupp0r4• 4 years ago

"With Electron you have full access to Node APIs, so a hacker could easily exploit the very powerful Node APIs."

This is not true, `nodeIntegration` has been disabled by default years ago in Electron 5.0 [1]. The default in Electron 20 will be a sandboxed renderer process that can't even read files from disk [2]. Security in Electron is great if you follow their security guidelines [3].

[1] https://www.electronjs.org/docs/latest/breaking-changes#plan...

[2] https://www.electronjs.org/docs/latest/breaking-changes#plan...

[3] https://www.electronjs.org/docs/latest/tutorial/security

catlifeonmars3• 4 years ago

I can’t tell you how many electron projects I’ve seen where “nodeIntegration” is explicitly turned on.

jupp0r4• 4 years ago

Having worked on an electron app for several years I can tell you that that's really just laziness by respective dev teams. It's not pretty to use contextBridge and IPC, it just requires some extra work. Electron itself did a great job making this easier and easier over the years.

bobblywobbles• 4 years ago

#6 - Security "Tauri is very secure by default, on the other hand I can't say the same about Electron... With Electron you have full access to Node APIs, so a hacker could easily exploit the very powerful Node APIs."

It's fair to believe this, given there's so much material out on the web affirming the fact. I've written about this at length in other places; applications with Electron pre version 5 [0] (released April 2019) were not secure. It's entirely possible and easy to build a secure Electron app today. I started building a secure app Electron template in 2020 [1] (that I still maintain) to address this security issue. I've also written about a history of the framework [2] and steps to build your own Electron app with today's best practices [3].

[0] https://github.com/electron/electron/releases/tag/v5.0.0 [1] - https://github.com/reZach/secure-electron-template [2] - https://www.debugandrelease.com/the-ultimate-electron-guide/ [3] - https://www.debugandrelease.com/creating-a-simple-electron-a...

atwood22• 4 years ago

It's _possible_ to build a secure Electron app, but it's also very easy to build an insecure Electron app. Even if you follow best practices regarding context isolation, it's very easy to introduce a subtle security issue like

    contextBridge.exposeInMainWorld('myAPI', {
      send: ipcRenderer.send
    })

frutiger• 4 years ago

This is a weird claim anyway.

If you're loading first-party content into the view, then it's no less secure than running, e.g. a Node.js script (or Python, Ruby, C++ program, Rust program, etc.) as the current user. A program you downloaded being able to do things it's supposed to do is generally a feature, not a bug.

If you are loading third-party content, then sure, it's a completely different ball game.

davej• 4 years ago

A missing point of comparison is that Electron also has far more desktop APIs available. Electron also has support for some advanced primitives like BrowserViews which enable some very sophisticated use cases.

Dr_ReD• 4 years ago

As I see it, the difference between the Tauri approach and Electron becomes visible when you have multiple apps running.

Each Electron app will load its own browser back-end in RAM, while all tauri apps will share the same runtime on disk and in RAM.

This makes for quite a big difference as the number of running apps grows.

tambourine_man• 4 years ago

The Tauri app is using more modern staff

Probably meant “stack”, right?

GolDDranks2• 4 years ago

I'm unable to access the site. It just keeps "verifying that I'm human", and after I do that, it glitches a bit and demands to do that again :(

GolDDranks2• 4 years ago

Turns out that if I switch from Firefox to Chrome, it works. This sucks :(

abhaysrivastav• 4 years ago

Tauri bundle size is 2.5 mb or 25 mb ?

c-smile• 4 years ago

Tauri:

   Test CPU RAM GPU
   Idle 1% ~ 80MB 0%

For the comparison, Sciter:

   Idle 0.01% ~ 40MB 0%

With startup time (minimal hello world) 200ms

As of memory consumption: the bulk amount is in graphics backend - Direct2D in case of Sciter. I believe the same cap applies to Tauri and Electron.

KronisLV2• 4 years ago

Shipping an app without auto update in 2022 is a no go. If your user has to manually download every update I don't think they are going to be happy.

Honestly, in certain crowds the opposite is true. Having to install updates for software that is for all purposes feature complete is incredibly annoying, if you don't need an actual bug fix for something that impacts your workflow.

Sure, there can be security concerns, like in software that's used to sign documents and whatnot, but for most local software for things like content creation, updates are a nuisance a lot of the time.

Consider something like LibreOffice - if things work for me, I don't want some update that could cause a flawed re-install to happen behind the scenes and lose some of my preferences, file history, or mess with anything else in my workflow along the way. I am okay with manually installing the latest version once per year or something.

catlifeonmars3• 4 years ago

When it comes to security concerns, it’s not just about what you can do within an exploited binary. There’s also a lateral movement component: specifically the binary could be used to achieve privilege escalation or manipulated to write to the filesystem by controlling the input, etc.

KronisLV2• 4 years ago

Certainly, you're right there. Though do we need auto updates for addressing that, with all of the risks and annoyances that come with that mechanism?

For example, something like GitLab doesn't have automatic updates (in self-hosted versions) and seems to get by just fine with sufficiently scary update notices for serious CVEs, for example: https://about.gitlab.com/releases/2022/08/22/critical-securi...

Of course, those who just don't care won't even bother with those updates and the consequences are obvious. Automatic updates would prevent that, but then again, the backlash in the Ubuntu community for having snap packages on servers (and to a lesser degree on desktop) would suggest that that's just not enough to get people to buy into it.

One could also claim that server software and desktop software are entirely different beasts, but personally I'd prefer to update software on my desktop PC through apt or another standard mechanism (when I want, from sources I trust), as opposed to every piece of software deciding on their own bespoke update mechanism.

Personally, I don't really have a good answer. Both approaches are somewhat flawed, just in different ways to different folks in different circumstances.

WhyNotHugo2• 4 years ago

Shipping an app without auto update in 2022 is a no go.

I don't agree with this at all. Shipping an OS with no auto-update mechanism for apps is a no-go. Applications don't need to re-implement such basic functionality.

Imagine if every single desktop application had to re-implement this. The burden on developers would be huge, applications would be enormous, and the system would be a mess to manage or use.

johnisgood• 4 years ago

And here I am still using Tcl/Tk and wxWidgets.

schemescape• 4 years ago

I was expecting Tauri to be lightweight, but it appears to have 1200+ dependencies [1]. Does this mean that if you want to publish an app based on Tauri, you'll need to put those 1200+ copyright notices somewhere in your app?

Compared to Electron, this probably is actually an improvement, but I was kind of expecting Tauri to be a thin layer, ideally with an easy-to-add copyright notice (instead of "it is your responsibility to verify that you are complying with all upstream licenses" [1]).

[1] https://tauri.app/about/architecture/#license

Existenceblinks• 4 years ago

I wish Zig desktop app framework happens. Its barrier to entry is much lower. It could bring 2-3x of developer pools into whichever win the battle.

Tauri vs. Electron – Real world application

Related Stories