Is Electron Really That Bad?
I’ve been thinking about this video by Theo Browne for the past few days, especially in the aftermath of my story about working on the iPad and realizing its best apps are actually web apps.
I think Theo did a great job contextualizing the history of Electron and how we got to this point where the majority of desktop apps are built with it. There are two sections of the video that stood out to me and I want to highlight here. First, this observation – which I strongly agree with – regarding the desktop apps we ended up having thanks to Electron and why we often consider them “buggy”[…]
[…]
As documented in the thread from late 2023, this is a common issue for the majority of AI clients built with SwiftUI, which is often less efficient than Electron when it comes to rendering real-time chat messages. Ironic.
i think the weirdest part of this article is hearing that chromium is more efficient than SwiftUI.
is that just for specific things or is it across the board?
[It] seems they’re talking about text rendering. SwiftUI is really bad at that, this is why I’m using UIKit for the document editor in PaperVault.
It’s not really surprising that Chromium is super optimized for rendering Web text. On the other hand, that’s a common thing that apps need to do, so it would be good to have a better native story.
For years, I’ve wanted to write a post called “The web won” which is very similar to what @viticci wrote here -- my aim was desktop more than mobile, but this is also especially true on the iPad and to @isaiah’s point, what makes this worse on mobile/iPad is the state of PWAs in Safari/WebKit.
Man I’m so happy I am in JavaScript land. Debugging just works and compile times are instant.
When I started writing apps, the availability and quality of developer tools was considered to be an advantage for native development vs. the Web. These days, I still think native APIs usually lead to better apps—though there are some awful Catalyst and SwiftUI apps that would have been better as Electron—but the Web tooling has really improved. I think many would now consider it a strong advantage.
JavaScript got 25+ years of work from many different parties. Mac developers got Swift, which I generally like and much prefer to JavaScript. But, while JavaScript is gaining many of the benefits of other systems, while retaining its dynamism, Apple is forfeiting former strengths. Swift made compilation much slower. Debugging is still slow and arguably worse than before. There are more compiler and linking bugs. There’s no more Fix and Continue. SwiftUI is more opaque than Cocoa.
Web technologies also seem to provide a more stable development target—do you hear about Web developers planning their year around seasonal beta testing and breakage?—and better documentation. An integrated development stack would seem to offer potential advantages, but offsetting that on the Web side are open source, cross-platform, distribution outside the App Store, and legions of developers and companies, now getting multiplied by AI.
Previously:
- The Subjective Charms of Objective-C
- Claude for Mac
- Xcode 16.3
- Tim, Don’t Kill My Vibe
- Whither Swift Assist?
- Elegy for the Native Mac App
- Spark Switches to Electron and Subscriptions
- Performance of Microsoft Teams
- Mac Software Stagnation
- Catching Native Apps
- The Persistent Gravity of Cross Platform
- The Era of Visual Studio Code
- Rebuilding Slack on the Desktop
- Electron and the Decline of Native Apps
- “It’s a Coup”
14 Comments RSS · Twitter · Mastodon
While I've never found an Electron app as good as a native app, I've also never found a Native app as bad as a Catalyst app - even the first party ones from Apple. So much basic stuff, and it's hard to know if it's because the APIs are garbage, or because Catalyst just inherently attracts iPad-first developers who are bad at doing Mac apps.
Take Mona, for example - its a Catalyst port of the iPad app, and has no understanding of window management, so every time it spawns a window for an image, it's in the dead centre of your display arrangement. If you have 3 displays, and Mona is on your right display, with your menubar in the centre, Mona spawns the image dead centre. you move the window across to where Mona is on the right, close the image window, and the next time an image is spawned, it's back to the centre.
Is that an API with no proper understanding of displays and window management, or a developer who hasn't taken into account Macs are more diverse than a single-screen laptop?
Or, why does it blur out column contents when resizing columns/ That's not mac-like behaviour, where live dragging and resizing is expected.
I'd love to hear about a *good* Catalyst app, because I'm yet to find one.
@MichaelTsai Here's the difference between Messaes.app and Mona - In Messages, which is on a non-menubar display, if I open an image someone has sent, that window spawns in front of messages on that display. If I move that image window to a different display, and close it, app subsequent images open on that display. So messages.app recognises that there's a continuity of use, that by moving an image window to a different display, my intent is for images to open on that display going forward.
Mona, by contrast, always opens images dead centre, either based on the centre of the entire display constellation, or dead-centre of the menubar display, and perhaps the developer never considered that "displays have separate spaces" isn't the traditional, or only option for handling multiple displays on the Mac.
@Someone Yeah, Messages will remember the last window position, but if I have separate windows for mulitple conversations it doesn’t remember where they all go.
Not sure how things are in Catalyst land, but with AppKit this is not something the developer has to worry about. If you center a window it will center it with the display, not the constellation. And it knows that “center” is actually supposed to be bit above the mathematical center.
A great read on this topic, this paragraph on the "Why MarkEdit" section of the app GitHub page, from the developer: https://github.com/MarkEdit-app/MarkEdit/wiki/Why-MarkEdit#we-do-things-correctly
I remember being up in arms/despairing when 1Password went Electron...
These days I'm happy whenever an app chooses Electron over SwiftUI or porting an iPad app over. I have a far better experience with most Electron apps than I do with most SwiftUI apps.
macOS native apps used to be dramatically better than Electron, but those days are well past. Some apps are still better, but Apple is doing everything they can to stop that with their ever increasing screw tightening. And Electron has gotten quite good as countless hours of effort have been poured into making it better.
Electron is still a leaky abstraction. Basic stuff doesn’t work as expected. My biggest beef is that most of the apps ignore regional preferences set at the OS level. The quickest way to tell an electron app from a native one is when you notice the whacky datetime formatting.
It's pretty ridiculous that Swift UI / Catalyst often ends up as being worse than Electron.
Outside of the obscene memory and CPU usage, the big problem with Electron apps -- as I'm sure many of you have experienced -- is the way they don't adhere to OS conventions. Things like system-wide keystrokes don't work properly, or UI elements don't behave properly.
But somehow Apple managed to bungle Swift UI and Catalyst in the same way, even though it's presumably AppKit underlying it.
My current favorite example: keyboard focus doesn't work properly in them. I'll have Messages open and with keyboard focus, switch to another desktop, and then switch back to it again. Its window will be frontmost, its text field highlighted, and the insertion point will be blinking in it. But if I start typing, the text goes into a black hole. I have to deactivate the window and reactivate to get typing working again. I reproduced this in News as well. I think it applies to all Catalyst apps.
In fact, if it's not the foreground app, it still incorrectly shows the insertion point in whichever of its text fields last had focus.
Electron doesn't have either of these problems! There are tons of Mac-specific things that often don't work in Electron apps, but they at least get these basic things right.
It's a really sorry state of affairs. Almost every app on the Mac now doesn't behave properly. The only ones that do are the native apps made with AppKit.
Same story different day. Apple doesn’t care about developers, especially on the Mac.
They are too busy with…what exactly is more important that a rock solid software foundation for the Mac, the “tool we use to build all our products”?
What was this company founded to do again? Make amazing PCs that change the world?
Oh wait it was movies and TV shows that push their political viewpoints. That was it.
"keyboard focus doesn't work properly in them"
Focus behavior has been broken on OS X for a long time, particularly if you use multiple monitors and spaces. I regularly get into situations where I have to force-quit applications because they have an invisible modal window open that can't be found, activated, or closed.
One of the issues with Electron that Apple should acknowledge, is that those Electron apps which don't adhere to HIG, undermine the platform and in turn one of the main reasons customers used to (past tense) buy Apple; great hardware and great software, built with a standard.
Once that goes out of the window, and my user experience for non OS-apps on mac is the same as it is on windows, that is one less reason to buy a Mac.
@CowMonkey That's why Apple changed the system default for Open / Save dialogues to be free-floating in the centre of a window, rather than as sheets that emerge from the title bar - because that's what webtech / non-native things can do easily, and leaving native apps are they were would just make it apparent how badly "native" Mac software is trending.
"that is one less reason to buy a Mac"
Ironically, this is good for us. Just like the web allowed Macs to become popular in the 00s because many apps that forced people to use Windows became web apps, this now allows Mac users to switch to Linux because many native apps they still use are just Electron apps.
As a long time native dev., I find myself no longer being so adamant against web apps on my desktop. There are some great examples including VSCode, which I use regularly often forgetting that it’s an Electron app.
What I’m still adamant about however is JavaScript. I know it’s wishful thinking but it needs to die. Like yesterday. The language was, is and probably will remain so, an absolute horror.
These days I often find myself coding web apps in Dart which is so much more sane a language.