Is Electron Really That Bad?

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.

@Someone Yeah, even the flagship Messages.app doesn’t remember window positions properly.

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

The reason why Catalyst sucks at a lot of stuff is because Apple deliberately chooses to not give developer access to basic AppKit APIs underneath which are public in AppKit. Even setting a window’s frame is considered a “request” that could pass back an error in a completion block. Passing data to a new window in Catalyst is ridiculously complicated using UIKit “scene” apis. Current Apple overuses completion blocks, these “configuration” objects etc.

Catalyst could’ve been good, Apple just did a terrible job with it and it seems they have given up on it. SwiftUI on the other hand, i dont think can ever be good.

Electron won because Apple's developer strategy over the last decade failed:

- Multiplatform is a common business requirement. Apple refuses to bring back Yellowbox or acknowledge non-Apple platforms exist.
- Apple's dev stack doesn't offer 10x speed or 10x simplicity to produce on Apple platforms. You still have to sweat the details (which Apple rarely does). The frameworks have not kept up with user and dev expectations. Meanwhile, it's not radically difficult to build a web app.
- Hostile developer outreach. Poor experiences with app review, bug reports, and a "deal with it" attitude towards yearly breaking changes.
- Apple's lost the UI/UX high-ground. "They don't have any taste". The HIG is gone. Catalyst and SwiftUI are negative starting points. There's no standard anymore, just common design patterns. That web apps are so widely-accepted proves the shift.
- Going all-in on Swift instead of building out the frameworks. Frameworks matter a lot more than the language. Languages are now interchangeable commodities via LLMs. Users don't care if you used Swift or js.

Ask yourself: Is Apple more likely to completely reverse course or double-down?

"Skate to where the puck is going to be."

One has to wonder what the trajectory of Apple would have been, if Lattner had never been there to put them on the Swift path. A new version of Obj-C, continued investment in AppKit etc, software only made by people competent to use Obj-C, the political centre of gravity remaining with the old NeXTSTEP-evolved technologies...

Expect the same to happen with React Native on mobile. Other than for hobbyist or niche apps there’s no reason left to use native. It happened to Microsoft years ago and they have successfully pivoted away (they maintain both the Windows and Mac React Native stacks), and it is happening to Apple now. They saw where the puck was going and ignored it.

I mean, yes, the obvious advantage of web-apps is that they're on the web. (And they can still be sovereign if you self-host, which it's as good a time as ever to do.)

And all those people who panned the iPad when it first came out for being an oversized iPhone optimised for content consumption in a web browser? Absolutely correct!

From original article:

> Even if you think you made up your mind about Electron years ago, I suggest watching the entire video and considering whether this crusade against more accessible

I have to stop you there. Whatever web-apps may be, they are not more accessible! That is literally the exception that proves the rule that web-apps aren't native, which is probably why people meekly avoid talking about it.

It is right to point to Apple's failure to embrace the web whilst squeezing out their own shitty cross-platform toolkits, I think, without simply apologising for some of the worst apps ever written. PHP rightly has a reputation for encouraging security vulnerabilities in web-apps, and Electron rightly has a reputation for slow, fat, not native and questionably inaccessible desktop apps. Of course, in both cases, there are great exceptions, but let's be honest here, making Electron look good is only possible if you're very selective in your criteria.

And if you declare your fellow developers incompetent, of course. That's definitely a winning strategy.

I think this really reflects the classic proprietary -> standardization lifecycle. When there are still innovations to be made in a certain space (like desktop software platforms in the 90s/2000s or mobile software platforms in the 2000s/2010s), a company like Apple can have the best platform by moving quickly and innovating. As these spaces mature and there's less innovation to be done, the benefits of standardization begin to overwhelm the benefits of proprietary control.

I don't think this really even has much to do with the state of Apple's developer platforms. I certainly have my complaints about SwiftUI, but even if SwiftUI was perfect, the companies that are choosing Electron are doing so for the benefits of standardization and being cross-platform. It's not like Windows is faring any better than macOS in terms of keeping its native software scene alive; if anything Windows is even more of a native software ghost town.