"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].
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.
Having worked as a developer for several years I can tell you that you should never underestimate both the time pressure our professional peers are under and their laziness. If I can hit the deadline by sitting that bool true, vs spend a week learning a new tech while I have 4 other "Critical" tickets in queue. I'll probably set the bool to true and so penance for it later.
Yeah, it's a sad reality. Thankfully the market is good enough that we have the chance to choose a job where we can make these decisions ourselves and live up to a higher standard.
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.
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.
CSS evolves and there’s always some new funky selector or effect coming, but the whole point is that you don’t need to follow this year’s latest hotness. If you slap rounded corners and box-shadow (very old by now) you have 90% of what Apple calls design lately. For Windows “metro” you don’t even need rounded corners :)
> but the whole point is that you don’t need to follow this year’s latest hotness
You might not have a choice. Sometimes even seemingly trivial APIs/features like SVG, flexbox, or audio/video behave slightly differently in different browsers, and it's easy to sink a lot of time into debugging these differences. I'm not saying the effort isn't ever worth it, and it's certainly better now than it ever was in the past, but I think you're underestimating the amount of work it takes to properly support a complex web app across all modern browsers.
With that said, if you're just using web technologies to throw together a UI to slap on your native app that does all the heavy lifting, then sure, maybe using something like Tauri is worth it. Even then, it might not be worth the QA burden of having to test all UI changes against every supported platform, and then the support burden of getting platform-specific bug reports.
> Fyi you need to optimize for two browsers only: chromium (edge) is the webview on windows, and webkit is the webview on linux and macos.
You're right, I keep forgetting that Microsoft has switched to Blink. It's still a pain if you're a Windows dev who needs to test on WebKit. Or is there an easy way to test that these days?
> I’m curious about the svg and flexbox issues you mentioned. I have not experienced any differences with those across systems and browsers.
To be fair, the differences I was thinking of were mostly between Gecko and Blink, so they're not really relevant to Blink vs WebKit. It's been many years since I've worked directly with SVGs, but I remember there being major differences between how different browser engines interpreted masks and some other features of SVG. I also think they scaled SVGs differently. The flexbox issue I'm thinking of had to do with how Gecko and Blink handled `height: 100%` inside a flexbox container that does not have a set height. I don't remember the exact difference, but I think Chrome assigned a height of 0 to the element, whereas Firefox greedily took up all of the available space, or something like that. Like I said, it's been a few years, so take all of that with a grain of salt. I just remember spending far too much time debugging those sorts of issues. :)
I’ve been writing web apps professionally for lovely browsers like IE6, Android 3.0, and Blackberry. I know when CSS can be hard to get working. 2022 WebViews are a walk in the park.
Yes yes, I don't mean to complain. :) Web dev these days is definitely a breeze compared to the "old days". I just don't like when people assume that cross-browser testing is no longer necessary at all, because there are still differences, especially if you use any of the newer or more obscure APIs.
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.
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.
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.
But that's an Apple problem, not a "you" problem in that case. In Electron the security burden for tracking Chromium CVEs and sending updates out is entirely yours, whereas with Tauri you outsource it. In Electron, Chromium CVEs are your CVEs. In Tauri, Safari CVEs remain Apple's CVEs and technically entirely outside the scope of your application bundle. The trade-off for "old macOS webviews" is that it's not your problem other than general, basic old pre-Chromium hegemony HTML kindness of building web apps that gracefully fail if features aren't available, which is probably what you should do anyway?
Your users don't care whose fault it is. Your app isn't working. You can choose to cut those users off, and that's totally an option...sometimes.
Mac users are probably a little more tolerant of this than non-Mac users, because of the general upgrade treadmill, but whether you can get away with it is a question only you can answer for your app.
That's still a very different class of problem from a CVE break of a single-point-of-failure is the point. Someone decides to use your Electron app's old Chromium build and a known CVE in it as a target vector for infecting or remote controlling user's machines is a very different problem from "because we are using system webviews this small CSS/JS feature doesn't work in this version of macOS, please upgrade". Even if the user rightfully blames you the app developer for both issues and doesn't allow you to point fingers upstream, one is a severe security threat that can destroy entire brands and the other is "mere tarnish" on a brand. (I know which class of problem I'd rather deal with, given the choice here.)
This actually makes me think Electron will be a lot easier to support. Because at least you'd be able to control which version of Chromium your app ships with. If you're using Tauri, you'll need to support all the different versions of WebView that are out there.
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.
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
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.
No, Electron cannot reuse Chromium libraries. Every Electron app bundles and loads its own copy of Chromium; it’s bound to that specific version and can’t share it with any other app. Also, Chrome isn’t Chromium; it may be compiled from the same code, but that doesn’t allow the OS to substitute one for the other.
you're correct, the chromium part is indeed statically linked, my only argument will be that html/css/js/webapi support, where chromium is more complete than whatever Tauri uses on each platform. for that alone, I will bear with more memory/cpu. plus there are more developers good at js than Rust.
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. :)
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?
I think it’s safe to assume that of anything written in something which doesn’t bundle an entire browser.
Though I do think it’s unrealistic that the legions of JavaScript devs are going to learn rust to make simple desktop apps because it doesn’t really have a reputation of being an easy language to learn.
The UI part of the app with its HTML/CSS/Javascript is normally the most the memory hungry part - there won't be a huge difference there between tauri and electron.
It depends on how big your app is. The problem with Electron is that it bundles its own installation of Chromium, so if you have 5 Electron apps, you have 5 instances of Chromium taking up memory. With something like Tauri, the system web view is used, which is likely already loaded into memory, so the marginal memory usage of each additional application is very small.
A big enough application will dwarf Chromium's memory usage with its own, but for smaller apps, the cost of running your own Chromium instance will dominate your app's memory overhead.
> Do you think it's unreasonable to assume that an app written BY ME in Rust will be smaller, use less memory and be safer than a similar app written in JavaScript?
No, it won't be. You gotta weigh years if not decades of Node/JS experience vs 0 years of Rust experience of the average dev. Development time will be far shorter too.
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.
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.
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...
> #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].
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
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.
"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.
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
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.
> 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.
> 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)?
> 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.
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.
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.
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.
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"
I've embedded a rust logic core into electron, so yes, anything that can expose a C API can be loaded into electron.
That said, after playing around with Tauri a bit I have to say it makes it magnitudes easier to embed rust. So if your target is rust, it's a much nicer option.
> 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.
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.
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.
> 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.
> Personally, I don't really have a good answer. Both approaches are somewhat flawed, just in different ways to different folks in different circumstances.
You hit the nail on the head. It depends on the target market for your application. If your users do not expect to manually update, it’s probably a good idea to build an auto update mechanism that is opt-out or opt-in. It might not be worth it for other target markets though.
However, my point was that just because an application isn’t doing something critical, doesn’t make security vulnerabilities in that application harmless.
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.
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
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.
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.
> 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.
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]).
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.
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.
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...
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).
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.)
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.
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...
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.
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.
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