* Non-native UI toolkit
* Massive waste of resources (CPU, RAM, Battery, Disk). Consumption of 500 MB RAM for idle is the norm.
* Slow.
* Often issues with autonomous, local operation.
* Security -> Browser Engine
It is always better to use a well-working application with your native UI-Toolkit:
* Linux: Evolution, Geary, K-Mail, Claws, whatever TUI application you prefer. And Thunderbird.
* macOS: Apple Mail or Thunderbird.
* Windows: Please. Stop using Windows. You harm other people. Start with using Thunderbird :)
The “Electron” from Signal is one of the best applications using Electron. It is fat. Even in this case people resist. Signal isn’t supporting a stable API but:
https://github.com/boxdot/gurk-rs
TUI :)
Electron is used, when a company wants to save on developer. All users pay with suffering from bad UI and their hardware resources. In this case it is something nobody asked for?
Actually, Thunderbird is using the Mozilla browser as a runtime for the UI and a lot of its code, in exactly the same way as Electron apps are using Chrome and node.js. Even a lot of non-UI code in Thunderbird is implemented in JavaScript, including some of the protocols like POP3 [1].
The same is true for Firefox: Almost the entire Firefox UI is written as HTML page with JavaScript. In fact, Firefox, Thunderbird and their predecessor Mozilla Suite were the first desktop apps written as webapps, and are the direct precedessors of Electron. And they also show that it can be done well. You just have to do it well, which is not easy.
There was a reason for that decision: Netscape tried to implement all its UI natively on 3 platforms - Windows, Mac and Unix -, which was too difficult in practice to keep them in feature parity. The big new thing about Mozilla - apart from the Gecko engine - was to implement the UI of the desktop app as web app, and run the same code on all platforms. That idea is the technical foundation of Mozilla.
Electron is just using that same idea with Chrome and node.js.
The only reason why using Linux as desktop today is realistic, is that web apps put an end to the monopoly of native Windows apps - which was the ultimate goal the whole time.
/Ben Bucksch Long-time core developer of Thunderbird
Thunderbird is no different than Electron apps, though. It's built on a browser engine, renders UI written in HTML + CSS (+ XUL partially), consumes ~500MB of RAM on idle, etc.
That's because thunderbird is a full featured application. It contains a browser because you can actually use that browser. It's not using the browser as a mere presentation engine.
I use Thunderbird everywhere, but I want to contribute this to the conversation: you don’t have to have your email client open all day long. I open my email client few times a day, and that’s it. I do the same with my chats, but with the chats (especially the work ones) I’m expected to reply within minutes, unfortunately. And, well, that’s another topic.
For email, I mostly don’t care whether it takes too much RAM, if the app is usable. I work with it, then I close it. That’s my workflow, at least. I believe I’m not alone in this. My iPhone is the mini server that gets all the notifications for the emails I need. (By being connected with the default email client.) So, if I want to reply from my laptop, I’ll open my app. Otherwise it’s closed.
I guess you can do that. I have my Thunderbird open 24/7 for days on end. It does seem to occupy 700MB of RAM after a while. Firefox is way worse of course... I keep Signal desktop open too, sits around 160MB.
Flash was awesome. It was proprietary, unstable, insecure, but in other regards it was much better than competition at the time.
Electron is open-source, stable and secure (as long as you stay up to date).
You’re making a compliment.
> * Non-native UI toolkit
That’s a drawback, not a plus. You can’t easily style the app with CSS the way you want it (VSCode, Obsidian).
> * Massive waste of resources (CPU, RAM, Battery, Disk). Consumption of 500 MB RAM for idle is the norm.
Nonsense. Obsidian is sitting at 115 MB right now, zero CPU.
> * Slow.
Define slow.
> * Often issues with autonomous, local operation.
???
> * Security -> Browser Engine
The only real drawback so far. Can be mitigated by staying up to date.
> It is always better to use a well-working application with your native UI-toolkit
It is always better to use whatever works best for you and solves your problems. Not OCDing around technology and not playing identity wars with crazy people online.
> Electron is used, when a company wants to save on developer.
Also a big plus. Features are being delivered to all platforms with less money spent. Win-win.
> All users pay with suffering from bad UI and their hardware resources. In this case it is something nobody asked for?
You need to seek therapy if you’re “suffering” from application using the toolkit.
P.S. Thunderbird performs worse than ANY Electron app I’ve ever used, and I’ve been using Electron since its inception.
> I do have two questions. The app on my macOS system is using 700MB RAM; is that for Electron?
Shall we discuss any of the other claims? Your security solution are constant updates?
Invests in efficiency scales with users. Most things which suck are caused by laziness and cost saving. It would be far more efficient to help either Evolution, K-Mail and Thunderbird with access to special APIs and keep them stable.
You know what does have theming? Win32, GTK and QT. GTK even uses CSS for it.
And unlike electron apps, when you change how a button looks in your GTK theme it affects all GTK apps rather than just the single electron app.
> Nonsense. Obsidian is sitting at 115 MB right now, zero CPU.
I just downloaded obsidian for the first time and launching it spawns 8(!) processes using a total of 827.3 MB of RAM. That's at the launch screen, before it's doing anything.
Of course it's using no CPU when idle. That's basically the bare minimum bar for any application. It's well known that javascript is at least an order of magnitude slower than C. That's where it's wasting CPU, not when it's idle.
> Define slow.
Well to start off with, I can count the seconds obsidian takes to start up. Most native apps I have installed (other than browsers) start faster than I can reasonably react.
> It's well known that javascript is at least an order of magnitude slower than C
If your base is base-2, yes. (It is well-understood that when you don't have your thumb on the scale—e.g. selecting, whether deliberately or carelessly, poor/pathological code to benchmark—that the expected slowdown factor of executing on a mainstream JS engine instead of AOT is in the neighborhood of 2x to 4x. Of course browsers JIT instead of AOT out of necessity—a constraint that doesn't apply to programs loaded from disk.)
https://josephg.com/blog/electron-is-flash-for-the-desktop/
It is always better to use a well-working application with your native UI-Toolkit: The “Electron” from Signal is one of the best applications using Electron. It is fat. Even in this case people resist. Signal isn’t supporting a stable API but: https://github.com/boxdot/gurk-rsTUI :)
Electron is used, when a company wants to save on developer. All users pay with suffering from bad UI and their hardware resources. In this case it is something nobody asked for?