Electron is a stop gap solution on a path away from natively compiled applications against the proprietary UI frameworks that come with mac or windows or any of the complex matrix of UI toolkits, window managers and other crap that essentially cause Linux to be a perpetually inconsistent UX nightmare. That stuff is increasingly less relevant for new applications.
For what it is worth, developers are voting with their feet and have been for quite some time. Native development is rarely worth the trouble any more. Native development is tedious and expensive and you have to repeat the effort across different platforms for desktops and mobile. It's been a long time since I came across job vacancies for desktop UI development. This stopped being a thing as soon as browsers started running Ajax applications.
The problems with Electron are mainly related to performance, which could be described as adequate for a lot of stuff but typically not great. That's a solvable problem though. Actually Electron as a run time is basically a short term solution to ensure web applications have somewhere to run that isn't a web browser. As web browsers evolve to support PWAs, the need for bundling separate things like Electron goes away. The real progress is continual improvements related to things like wasm, low level browser rendering optimizations, etc.
These days most normal users do most interesting stuff on a computer via web apps. E.g. Office 365 can be used in a browser. There's no native app for Google docs at all and many people happily read their email in a web browser. Popular applications like spotify, slack, skype, etc. are all glorified web applications either running on electron or something similar. Increasingly it's the native apps that look dated and out of place. On mobile especially, a lot that passes for native is in fact running mostly in web views. It's more about the packaging, appstore presence, and access to system services than it is about using the right UI toolkits.
Yes this has been a rather interesting development - it seems the purpose of the native apis is now becoming just to bootstrap the browser with the browser implementors being the sole users of the native platform apis. Will be really interesting to watch what happens here long term.
Some open questions in my mind for this are
1. Will the browser evolve to cover every use case? (Like AAA games, high performance IO)
2. What does this do for hardware vendors? Think over the years the hardware vendors had a good working relationship with Operating System vendors to surface new ISAs / APIs and make them available to developers, who could build killer apps for end users. For client workloads now new ISAs dont do anything unless they somehow get exposed through the browser.
3. If you are not a browser vendor what options do you have for introducing new computing paradigms ?
4. As the number of developers doing native development reduces to engineers who are implementing browsers the market for debuggers / profilers for native client development reduces. What effect does this have on tooling quality.
Would love any thoughts / speculations / ideas about the above.
A lot of this stuff is simply happening on merit. Nobody is being forced to use web based platforms, it just so happens to be a convenient option for a lot of developers.
Games have no native look and feel because they typically roll their own UIs. That makes them suitable for running in a browser sandbox. However, performance tends to be critical as is low level access to e.g. 3D hardware. So a lot of games where this is important will likely stay native for as long that that is the faster option. However, as wasm improves and access to relevant features from browsers improves, that will become an interesting target for more game developers. Portability of games is important and a source of a lot of overhead. Targeting e.g. xbox, playstation, windows, osx, android, and IOS requires doing a lot of platform independent stuff. Most of the mainstream game engines are effectively doing a lot of similar stuff as web browsers and there's an increasing overlap in terms of technologies. I expect wasm to be a key enabler here.
2 and 3 are interesting because this vastly simplifies creating new formfactors. Look e.g. at magic leap launching their AR platform and partnering with Firefox to get their VR browser going on a completely new HW and SW plaform for AR. I'd say this creates lots of opportunities because this stuff is open source and standardized to the point where competing implementations are interoperable to a very large degree. So, for magic leap that means a lot of stuff out there, should just work (barring UX issues resulting from AR).
4, again merit. This stuff is happening because developers are voting with their feet and also raising the bar in terms of tool quality. Wasm means that there is actually a renaissance in tool quality and innovation for native development. Just look at what the Rust community is doing for WASM and embedded development. Lots of new tools, libraries, and technology aimed at supporting both.
Electron isn't the end game, it's a flawed, but workable solution to the problem of having to support too many platforms on a limited budget. I can't wait till we have something better, but I haven't seen a better solution yet. There are not many companies that can afford to build first class native apps for every platform.
Progressive Web Apps are better solution. Chrome and Edge have PWA installation on desktop, and work is already under way for missing native features, like file system access. In a year or so they will replace need for Electron completely. Although they will never be as good integrated or performant as real native apps.
PWA certainly solve some challenges around installation and delivery, but they don't do that without additional tradeoffs, and you still end up with an electron style app, which is what Gruber doesn't like.
Eventually if electron gets popular enough you will have only one additional browser per system - the linux distriburion packaged shared electron. (e.g. https://www.archlinux.org/packages/community/x86_64/electron... ) (not sure but even that could use a shared choromium lib - or am i wrong?)
It is the same as having shared GTK or QT libraries (both with embedded web engine BTW - so plenty of engines already), or having a shared global python deployment with shared global packages (from these you sometimes need two: v2 and v3)
So you will have one extra component per system.
In Windows world maybe you will have one additional electron component per app, but there, it is the "normal" way (you have qt dlls in every qt app etc...) anyway, so not much difference compared to other frameworks there too.
Those are useful links but are they don't give PWA's the same rights as native apps.
Chrome apps do use HTML and JavaScript but aren't PWA's. The API's and sandboxing is different.
There are many useful HTML5 API's, but they don't require code signing as far as I know, and they don't have the same permissions as Android apps. (The permission system is entirely different.)
You are missing an important thing on how PWA are supposed to be coded.
PWAs are supposed to check the avaialbe sandbox APIs and adapt accordingly.
So if a PWA is running on Windows on an UWP context, it can check it and then access UWP APIs, if they are running on Chrome OS instead, then check accordingly and act upon it.
Finally if only play old HTML 5 APIs are available, then make the best of it.
That is the whole point of Progressive, to enhance the experience depending on the surrounding context.
I thought the point of PWA would be ‘free’ compatibility with every OS that can run PWA. Checking for several different APIs and using the appropriate one seems counter to this.
it's a flawed, but workable solution to the problem of having to support too many platforms on a limited budget.
If that’s the case, then why aren’t we collectively here on Hacker News celebrating Microsoft’s decision to ditch Edge in favor of (some flavor of) Chrome?
Monoculture is unambiguously bad, so anything that contributes to the destruction of the Tower of Babel is good.
We should all boycot Electon in favor of native solutions specific to each platform. Budget be damned.
There are more free apps to choose from. For example, the two Electron apps I'm most familiar with (Atom and VS Code) are given away for free. And Google apps are free.
Free beats getting all the keyboard shortcuts right.
I think the issue is straightforward, it is simple economics. Nobody wants to spend a lot of money to rewrite applications three or more times. Sure, there are some people who really want a very specific user interface for their specific system, and there are a number of cases where a non-native application cannot do the job. But most users frankly don't care that much, they just want things to work. A vast number of applications can be done using web technologies, without rewriting the application multiple times, and that saves a pile of money. That kind of focus also makes it a lot easier to make one good product instead of three bad ones.
Native user applications are not disappearing, but they are becoming rarer, and that is to be expected.
Electron really needs to heed the experiences of the past, if they want to really thrive.
Smalltalk had what was both an utopian and a dystopian story and experience when it came to cross platform. For most Smalltalks, the abstract runtime memory model ran bit identically across all platforms. Essentially, everything ran the same ISA and runtime memory model as implemented by the Virtual Machine. Squeak Smalltalk runs bit identically across many dozens of combinations of hardware and OS.
The dystopian part came primarily from 1) lack of polish in the deployment tools, 2) high resource requirements at first, creating a poor performance reputation that never went away, and 3) a development culture that never prioritized UX and look and feel.
EDIT: And it's not just Smalltalk that had those pitfalls. It's also Java Swing. Tcl/Tk. Also, to one extent or another, any number of cross platform tools and libraries. Given we've been at it so long, and the same mistakes have happened so many times, the pitfalls for cross platform GUI must be quite severe and hard to see.
While I’m in full-on you-kids-get-the-hell-off-my-lawn mode here, let me mention another Mojave gripe that is clearly the work of young developers at Apple. The Finder’s File → Show Original command has had the shortcut ⌘R since, I think, System 6. (Select an alias or symlink and this command will reveal the original file.)
This is exactly the kind of arrogant, smarmy stuff which alienates power users. "Who uses that stuff anymore?" Well, quite often, it's power users and influencers, and quite often, there was zero research done to see if that's the case before the feature is removed by young devs.
> And it's not just Smalltalk that had those pitfalls. It's also Java Swing. Tcl/Tk. Also, to one extent or another, any number of cross platform tools and libraries. Given we've been at it so long, and the same mistakes have happened so many times, the pitfalls for cross platform GUI must be quite severe and hard to see.
My guess is that the platform creators tend to put a lot of money into look and feel for their native components. This is hard to match for a small open source project (or anyone, really).
The web platform gets around this by being flexible enough for the application creator to create a polished look and feel themselves, and ubiquitous enough for many designers and developers to know how to use it. That's also part of what makes it so resource intensive.
My guess is that the platform creators tend to put a lot of money into look and feel for their native components. This is hard to match for a small open source project (or anyone, really).
It sounds like you have an unspoken assumption that only the web has that degree of flexibility. That's false, however.
The web platform gets around this by being flexible enough for the application creator to create a polished look and feel themselves, and ubiquitous enough for many designers and developers to know how to use it. That's also part of what makes it so resource intensive.
Smalltalk was flexible enough for anyone to create such a look and feel. Everything above the border of the VM itself was in the class library and was modifiable in Smalltalk, and most everything was in the class library. However, as a member of that community I can attest that many felt the need of this, but no one wanted to do it. Everyone who needed that level of polish was on a professional project and couldn't afford to devote that many resources to it, and everyone else was fine with the "developer" level UI.
The Web after the "Web 2.0" period grew both a developer and user culture emphasizing good looking interfaces with great UX. This was also increased by the aesthetics of smartphones and tablets after the appearance of the iPhone. The tools on the web are a bit less flexible than what was available to many earlier environments. However, there were more people with more motivation to make things look good.
It's not about flexibility and technical superiority. It's about numbers and motivation.
Pharo's new graphics system, Bloc, is going to change some of this. Already the guys rewriting GToolkit are experimenting with much better looking and more interesting UIs. And one of the backends is the same framework mozilla uses in their browser.
> My guess is that the platform creators tend to put a lot of money into look and feel for their native components. This is hard to match for a small open source project (or anyone, really).
I wonder whether the problem for cross-platform GUI can be solved by brute force. Swing had a terrible reputation for being slow and ugly, yet today I find Intellij (which is based on Swing) fast and good looking.
The brute-force work there is in IntelliJ, not in Swing – they've reimplemented the most broken Swing components, like the menu bar. Other Swing applications are still slow, ugly and buggy. (And despite all their work, IntelliJ still suffers from Swing bugs.)
I've gotten bitten by the Smalltalk bug recently and I've been thinking about this a lot. Smalltalk in the form of Smalltalk-80, Squeak, and Pharo is a fascinating environment, but I wish it were developed into a full-fledged operating system with an opinionistic set of UI guidelines (such as the Apple Human Interface Guidelines from the classic Mac days). Imagine had applications similar to MacPaint and MacWrite been written in Smalltalk. Even better, in my opinion, is to take advantage of the dynamic, object-oriented environment of Smalltalk and create component-based GUIs similar to Apple's OpenDoc efforts. I would use such a system today if there were any apps available.
I think Smalltalk (or something similar to what I've heard about Lisp machines from the 1980s) is the perfect environment for creating such a dynamic environments, and I think Smalltalk would have been better received had it been molded into an operating system instead of sitting on top of another operating system with the whole impedance mismatch between the host and Smalltalk environments.
If it's a competitive advantage for your desktop product to use the native system frameworks with the platform preferred language (Cocoa/Swift or UWP/C#), I believe its just as easy to justify the development time and cost to build your product today as it was 10 years ago.
The main change I see is 2 things...
1. Companies now write all internal software using the web both for deployment and accessibility reasons and for storing things in the data center.
2. Consumers have mostly moved on to mobile devices.
Honestly, if you need a desktop platform at home for anything other than hard core use cases (photo editing, software development, music production, etc.) those tools have largely been written and established.
> Honestly, if you need a desktop platform at home for anything other than hard core use cases (photo editing, software development, music production, etc.) those tools have largely been written and established.
Yes, and many of them do not make a convincing case for "native=high performance"
Our desktop app is an Electron app that adds features to our web app while “containing” it.
The justification for pure native apps just isn’t there. Engineering effort + maintenance costs are too high.
That, and NS* frameworks just kind of suck. Apple is trying to change that with the UIKit port to macOS but the apps that use it look and feel terrible (Home being one example) right now.
The "native" desktop experience is insanely important and I think you can get there with Electron but it's not going to do it for you out of the box.
First. The bloat issue is definitely a real problem. Expect a 100MB app and 100-200MB of RAM usage. You wouldn't want to build calc or anything in Electron.
Additionally, things like context menus are next to impossible to implement properly as they require you to jump back and forth between the node and chromium processes and it's an insane hurdle to jump through.
The upside is that you can do amazing things that you couldn't do before like REALLY nail web content rendering and manipulation and also use frameworks like React or Angular which your team might already have experience with.
If you're an app like Discord being able to ship a desktop app on Windows and MacOS without having to hire native teams is a huge win.
If done right, the UI widgets can 'feel' native but they're never going to be there 100%.
What we can do in the mean time:
- build something like Electron or Flutter that takes into consideration ALL platforms - not just desktop or mobile but BOTH at the same time.
- supports native features when necessary. Electron TRIES to do the right thing but often fails just due to the complexity involved.
We just need a React native for desktop that works well cross platform.
It’s so stupid that we keep on re-inventing the UI libraries that are already built into the operating system. They arare accessible, high performance and use very little extra memory since the resources are shared.
The problem is electron, not JavaScript. V8 folks work very hard to make JavaScript nimble and fast.
> jump back and forth between the node and chromium processes
So Electron runs two copies of V8?
Since Electron in control of all the components, why wouldn't they try to merge the Node part into the Chromium process, to gain faster data exchange and lower RAM footprint? Has this been attempted?
I think it's possible to do a good Electron-based application: Visual Studio Code comes immediately to mind (and Atom, although at least the last time I looked at it, Code seemed both less resource-intensive and more nimble). But after Code/Atom, there's...what, exactly? For that matter, I'm finding myself spending more time in BBEdit and Sublime Text these days, both of which are much faster and less resource-intensive than their cross-platform counterparts.
Is the benefit of getting your app out on multiple platforms faster worth the downside of having your app be a shitty citizen of every platform unless you put significant effort into platform-specific tweaks that make it not suck? The cross-platform editors that are the most obvious rebuttals to my observation in the last paragraph are Emacs and Vim, which have cross-platform cores with platform-specific GUI code. It seems like, if being cross-platform is important to your product/team, that old-school approach will nearly always get you much better results.
True, and I meant to mention that along with Emacs and Vim but spaced it while typing. It seems to be similar to those two in its approach.
They're all good reminders that being cross-platform isn't the issue; it's the way Electron does it that's more of a problem. (Qt-based apps are a lot more performant, although in my experience they stick out like sore thumbs among apps using the native GUI toolkits.)
Yeah, like everything, Electron is all about trade offs. It’s incredibly expensive and difficult to implement every new feature 3 different ways for three different clients. It’s very nice (and probably worth it) to just do it once, even if you lose some performance or small details that most users won’t notice.
I disagree that Spotify is a good Electron app (and I've never used Slack so I can't comment on that). I run Spotify on my work computer (Windows) and at home on my Mac and it's extremely resource heavy on both of them, and I often get various weird issues. It's the primary reason I've been moving back iTunes a bit, actually. I never knew it was Electron until now, and I think that explains why I've always hated the Spotify programs on both platforms I've used it on.
I don't think Spotify is Electron. They use CEF (and sponsor its development), and client side app code is primarily in webviews, but they've been doing that for much longer than Electron has existed.
And for what it's worth, I have never been dissatisfied with Spotify's client performance on any platform (Win/Mac/Gnu+Linux+XOrg/iOS).
I'd also disagree Slack is a good app. I've used it, Spotify, and a few others. I never understood the point. You're running a web page. It feels like a web page. It drains your resources just like a web page. Just because your web page runs in a window that doesn't have your web browser window frame doesn't make it native. It's a pointless exercise of tomfoolery.
Not to mention you have to install and update an app now. It's not even as convenient as the web.
And like Discord or Finda[1] did, wherever you need some parts of your software to be really fast or to interact with the OS you can use Rust under the hood. And you have the best of both worlds. Using knowned technologies with CSS/HTML and React/Redux for fast UI/UX iterations, with “native access” and performance with Rust.
This is the crux of the anti-Electron folks that I've never understood tbh.
All things being equal, I'm sure companies would love to develop their apps using native tooling and have them simple, beautiful, accessible etc. Doing this 3 times for 3 times the cost, as opposed to once some sacrifices is the obvious reason for this widespread adoption.
Well, the anti-Electron argument is that you're not necessarily doing it "three times for three times the cost." If you designed your app with the intention of being cross-platform to start with, you're writing it to have some kind of platform abstraction layer. The bulk of most applications isn't going to change.
That's undoubtedly still more expensive than doing everything Electron, sure. But it's going to produce a nicer application: lower resources, faster performance, working better with platform-specific features (e.g., macOS's Services menu). Maybe that's not worth it for all applications, but if Electron-style frameworks that lock their applications to the lowest common denominators become the norm, the overall quality of software drops.
When I say three times the cost, I primarily mean for the web, mobile and desktop. Not for the varying OS distributions.
Electron provides a means to handle all of those environments with some admitted drawbacks on desktop. I'm not a proponent of Electron, just stating (IMO) the likely reason for it's adoption.
I have no idea how this whole idea of doing something 3 times gained any momentum.
Do people not realize that you can use cross platform C++ libraries and essentially get the same program to compile on three different platforms, then just write it once? It really isn't that difficult. Use Qt, or Juce, or FLTK, the standard library and a couple of cross platform libraries for things like networking and you are in the clear.
The idea that anyone is actually maintaining three separate versions of a program is completely detached from reality.
I'm fully in support of cross platform frameworks, I just hate the Electron approach of taking the worst parts of a browser and putting it all into a gigantic, ran gobbling monstrosity.
There are good "non-native" frameworks - Qt comes to my mind first, but Flutter and the now seemingly revived WPF are also good contenders. Those are pretty great.
You can also do Electron well (VsCode), but almost no devs do it, which makes me question whether doing it well might require just as much effort as using something else.
> Doing this 3 times for 3 times the cost, as opposed to once some sacrifices is the obvious reason for this widespread adoption.
Are there any stats that back this up? It wouldn't surprise me if it was more than 3 times the cost given you'll likely have a larger team to coordinate.
It'll be interesting to see if Flutter, through Hummingbird, ends up getting any traction as an alternative to Electron. Not to mention with Marzipan on the horizon, what other cross-platform competitors will arise.
Yes Flutter could become an alternative to Electron, but it doesn't need Hummingbird for that - Flutter can be directly compiled as a native desktop application.
I recently tried to use new Swift features cause I wanted to build a native app. Unfortunately, my MacBook pro is too old to update to the newest Xcode which means I can't upgrade to the latest version of Swift. Fortunately, every other language doesn't discriminate against my 2011 MBP. This made me switch to building my app in Electron without any problems. Maybe this is far from the subject but I found it relevant because it was the very reason I started building in Electron and not a native MacOS app.
If the decline of native apps means the apps will be available on all platforms, because it's the same codebase then it's a welcome change. No more this app works on Windows, but not on Linux,etc.
But then of course the question arises why have different platforms at all?
Maybe you are happy with a race to the lowest common denominator in regards to quality and expectations, but IMO that serves any platform terribly.
Using a QT app within a GTK window manager always sticks out in numerous ways (though probably less than most Electron apps), just like these bloated web wrappers do to long time Mac users.
If I were a Linux user, I'd rather a well-thought out App using the native toolkit that adheres to the platform interface guidelines than this Wild West any day.
> If I were a Linux user, I'd rather a well-thought out App using the native toolkit
I agree if this is a choice. But the reality is often a non-existent Linux app, because "it's not worth it" to implement it for Linux or an app which comes much later than the windows version and is of subpar quality.
If that is the choice then I'd rather have a non-native app than no app at all.
Linux desktop usage is 1-2%, so in practice most apps won't be implemented for Linux if it has to be done natively.
Kap and VS Code are Electron apps that prove you can get it “right” but it is troubling that Apple’s own apps don’t seem to have the same quality that they used to.
VS Code might be a nice editor and relatively efficient Electron application resources wise, but it is definitely not native.
You can't even CMD + CTRL + D words to look up their definition, which is such a basic expectation of any native text input area in any real Mac app.
This doesn't excuse Apple, but it's hardly a good example to the contrary of what is terrible about Electron. Maybe for an IDE it matters less since almost all of them have terrible interfaces and the advantages of being able to write extensions for anywhere being more relevant than most apps, but Electron apps like Slack are still hot garbage compared to a native app for any platform.
To decry the mass adoption of Electron because the apps it makes aren't "Mac enough" is just crazy. Electron is a terrific solution for developers and users. Nothing prevents you from writing a Mac-y app with JS and CSS. I think what the author is really upset about is that not many people like Mac-like apps! The whole idea of a boutique Mac UI that obfuscates most functions and dumbs-down others simply isn't that appealing to anyone but noobs. Is there anything Mac-like about iTunes, or ProTools? Even Apple doesn't care about their boutique UI, as OP points out. If Electron can kill native apps, as a dev and a user, I'm all for it.
As a former Microsoft employee who used to work on Internet Explorer (I helped build the new developer tools), I will say I believe he's partly right here.
I do think it has a lot to do with Electron and I also think their acquisition of GitHub had a lot to do with this also. But maybe not for the reasons this author is thinking. I don't think they're thinking of it as a scourge or a performance problem but the opposite, a savior of the desktop so to speak.
To understand why I say this I think we have to go back and talk about the history of .NET, XAML and their relationship with Windows. It's interesting to note that XAML was originally created by shifting a lot of developer resources away from IE6 and onto the WPF team, this was why IE6 sat stagnant for a long time, the developers were gone! What they then made was the windows presentation foundation for what later became known as Longhorn, which ended up being a pretty large disaster. Longhorn largely failed because they attempted to rewrite the windows shell using .NET and WPF. At the time (and still frankly) WPF had lots of really bad memory leaks, memory consumption issues, GC issues and a variety of other bugs and performance issues. This is why Longhorn was scrapped and what they ended up doing is to straight up revert the Windows codebase back several years to pre-longhorn and then subsequently worked overtime for another 3 years to crank out the gem known as Vista. Some people don't remember Vista fondly but frankly it was a Hurculean effort and a genuine evolution considering the prior turmoil that caused it. Or, in other words, it could have been worse.
So ever since Longhorn the Windows team has had an extremely bitter attitude towards .NET. I don't think its completely fair as they essentially went all in on a brand new technology and .NET has done a lot of evolving since then but nonetheless that sentiment remains among some of the now top players in Microsoft. So effectively there is a sentiment that some of the largest disasters in Microsoft history (IE's fall from grace and multiple "bad" versions of Windows) are, essentially, totally the fault of gambling on .NET and losing. And that sentiment can sometimes show in decisions like this.
So when Microsoft went to make their new metro apps for windows 8/10, they almost didn't even support XAML apps but only C++ and javascript. It was only the passion of the .net developer community that pushed it over the edge and made them let .net into the store as a first class type of app in the app store.
But here we are now and the store is not super successful and writing html+js applications for the Windows Store Apps is very unpopular and painful and here they are virtually retiring WPF and acquiring new html desktop technologies and freeing up a lot of js+html developer resources...
So what I think they intend on doing is adding features to electron and windows store which would enable developers to easily ship electron apps directly to their store. To do this they're going to have to add in some significant work into electron to be able to access the sandbox store api's and make it as transparent as possible to the api's that are already there. I think they see this as _revitalizing_ desktop applications. Because right now one of the major complaints people have is not that its hard to make a windows app but its hard to make a windows app and a mac app and a linux app... If you have enough resources and those individual experiences are important enough to you then fine, make 2-3 native apps, but for a small operations it's just not wise for anyone tether themselves to a technology that only lets them deliver on one platform.
I'm surprised by John Gruber's lack of technical knowledge.
There is nothing wrong with web apps being used as UI for desktop apps. In fact Apple uses that approach in Apple Music since it's a web app made in Ember.js.
The problem with Electron (and similar projects like NWJS) is that it embeds Chromium and Node resulting in bloated apps.
It is perfectly possible to create a desktop app using WKWebView and Swift which are super performant and efficient.
What's a little confusing for an oldtimer like me is how developing for electron will be different from developing for an OS - don't you make a commitment to a platform that may or may not end up being your best bet?
For the consumer it's great, of course, each of the three big OSes basically allow you to run the same stuff and judging by VSCode performance can be okay.
Gruber's point is it's not "great." These apps do not feel like Mac apps and do not obey Mac app conventions. Even in VSCode, there is hardly a single interaction that behaves properly. Scrolling, cursor movements, menus, table selection, resizing, drag and drop: they all behave wrong.
The more apps like this, the more they erode the UI vocabulary that the Mac has built up.
I think it goes further than just eroding expected behaviour. There is a noticeable performance impact when using these Electron based apps. Idling in the background they'll happily drain your battery. Since consumers are using mobile devices more now, battery life is an important consideration. Scroll through text document on any electron app and check the processor usage. It's really surprising that you can get up to 60+% cpu usage.
Mac browsers are much more Mac-like than Electron apps, because they use native Mac APIs for these interactions. For example, Command-Z in Chrome highlights the menu properly because it's handled via the Mac UI frameworks, not intercepted by JS.
The Ctrl+Cmd+D example works in Chrome and doesn't in an Electron-based IDE I happen to have open now; likewise the right-click menu on selected text works in the former and not the latter. I presume Chrome uses Blink to render UI components within Chrome windows, but in most other respects it behaves like a native macOS app.
WebKit generally behaves reasonably well on macOS (which makes sense, with WebKit being Apple’s baby). Blink/chrome on the other hand, while behaving better than Gecko has eschewed many Mac specific behaviors, presumably for ease of cross platform development.
If it can be, it should. I'm only using electron for two reasons. I need access to a serial device, and I need to be able to package my web app to run offline.
Most users will only need to install the device shim.
For what it is worth, developers are voting with their feet and have been for quite some time. Native development is rarely worth the trouble any more. Native development is tedious and expensive and you have to repeat the effort across different platforms for desktops and mobile. It's been a long time since I came across job vacancies for desktop UI development. This stopped being a thing as soon as browsers started running Ajax applications.
The problems with Electron are mainly related to performance, which could be described as adequate for a lot of stuff but typically not great. That's a solvable problem though. Actually Electron as a run time is basically a short term solution to ensure web applications have somewhere to run that isn't a web browser. As web browsers evolve to support PWAs, the need for bundling separate things like Electron goes away. The real progress is continual improvements related to things like wasm, low level browser rendering optimizations, etc.
These days most normal users do most interesting stuff on a computer via web apps. E.g. Office 365 can be used in a browser. There's no native app for Google docs at all and many people happily read their email in a web browser. Popular applications like spotify, slack, skype, etc. are all glorified web applications either running on electron or something similar. Increasingly it's the native apps that look dated and out of place. On mobile especially, a lot that passes for native is in fact running mostly in web views. It's more about the packaging, appstore presence, and access to system services than it is about using the right UI toolkits.