> ... I tend to be at least as concerned that Electron apps are just lousy Mac citizens. It's not just that they don't look like other Mac apps, they don't support Mac UI conventions and frequently don't support system services and scriptability.

Which is the case with Chrome itself too...a pretty unpleasant experience on the Mac if you have finger memory or want to use your apps together. Sigh.

I also understand this critique but feel it's a bit hollow. Or at least I feel that despite billions of dollars in available funds the big software producers failed to create a solution that is better. They are simply unable or unwilling despite having the resources and a lock on the top engineering talent in the space.

I wish and hope that MS moving Edge to chromium is to provide a single host level run time for PWAs. It's a space they have flirted with and seem to be inching towards more quickly.

Also note that there is nothing keeping developers from adhering to Mac UI conventions that I know of. That's not a fault of Electron at all.

tl;dr - If Javascript and electron are winning it's because others are continually _failing_.

Adhering to Mac UX conventions is harder with Electron, because a lot of little things that apps get "for free" with the native toolkit have to be explicitly included or even re-implemented under Electron. Visual Studio Code, for instance, has explicit support written in it to be able to use macOS Services; earlier versions of Code just didn't work with them. If its UI was written in Cocoa, this would have just come along for the ride. And at least off the top of my head, I can't think of a single Electron-based app that I use which fully behaves like a Mac app in other subtle ways; for instance, Slack, Telegram, Atom, and Code all do their own weird things to control their settings rather than bring up a modeless preference window the way every native Mac app does. Maybe it's modal! Maybe it's modeless! Maybe it's a JSON file! Who the hell knows. Does it bring up any internal windows that look like the native OS's windows? Does it support all the common text editing keystrokes that Macs have supported since 1984? Does it even integrate with the system font selection system? [shrug emoji]

I presume this is true for other platforms/toolkits as well, and it's a tradeoff that doesn't get talked about as often as it probably should be. I'm not using a Mac because I woke up one day fifteen years ago and said, "You know, I'd love to pay a lot more for hardware than I probably should just so I can get minimalist industrial design, too few ports, and dubious keyboards." I use them because I like Mac UX conventions. I've talked to many people who actively prefer Windows UX conventions, or KDE or Gnome. I am not thrilled with the notion of a world where everything is a pseudo-native PWA.

> There may come a point in time when a well-written native app won't trounce an Electron-based app in terms of memory footprint, startup time, and integration with the host platform. But that time is not now, and it's silly to pretend otherwise.

It's also silly to pretend that users will notice or care, assuming a well written electron app. Again, look at VS Code. Now assume that the app is aimed at a non-technical audience who aren't going to be examining their resource monitors and who would never describe anything as a Mac citizen. If the customer doesn't notice or care, then the superiority of native apps does not exist.