It is likely that some of your desktop apps have been developed with Electron, a framework that combines Node.js, parts of Chromium, and a layer of native code. Apps like Visual Studio Code, Slack, Atom, WhatsApp, or even the installer for Microsoft's Visual Studio use it to build for Windows, macOS, and Linux. I've been working with and on Electron for years now, wrote a short guide on it, and am invested in the community.
Whenever a technology gains some favor, a sizable group will stand ready to decry that choice as terrible, the technology as fundamentally flawed, and the problems solved to not be as complex as the advocates make them out to be. Electron is no exception. Reasons commonly cited as an argument against it (like memory consumption, general performance, or app bundle size) are clearly not leaving a mark with developers or end users.
Commenting "Ugh, Electron" on HackerNews doesn't seem to work, so let's look at what you could do. Let's consider why developers choose it and how it currently beats other desktop software environments. Let's look at how you could defeat Electron.
Developer Productivity Matters
The term "cross-platform" is not well defined - at Microsoft, it usually means building for Windows 10, Xbox, and Windows Phone 10, excluding Windows 7. In the Apple world, we talk about code-portability between iOS, tvOS, watchOS, and macOS. Some frontend libraries simply mean that they support multiple screen sizes.
If you're building desktop apps, it means that you need to reach desktop users. Ground truth shows many Windows 7 and 10 users, some on the latest macOS versions, and a handful on various Linux distributions. For most Electron developers, code portability with mobile platforms, game consoles, or IoT devices is not a concern. Electron enables developers to target desktop platforms with high productivity and beats its competition in four main arenas.
Web Technologies for User Interfaces
Hate it if you must, but after years of iteration and a breathtaking number of frameworks, libraries, and even languages, web developers enjoy a smörgåsbord of amazing tools to work with. Hot-reloading the app you're working on doesn't grab attention anymore. That level of productivity is unmatched.
We don't need to just look at cross-platform technologies, even single-platform environments these days are years behind where web development is today. You might be comfortable in it, but Xcode hasn't improved its developer flows in years. In the Windows world, Microsoft seems to focus its efforts entirely on the Universal Windows Platform, which has no chance of running on Windows 7. For Linux, we're lacking any kind of consensus. I've seen adults yell at each other over gtk2 vs gtk3.
Including libchromiumcontent (Chrome's rendering engine) in Electron allows developers to build user interfaces that look, feel, and behave the same across platforms. Since the rendering engine is included, developers aren't limited to whatever IE11 on Windows 7 supports - one can build the whole app with Rust/WebAssembly if desired.
Electron offers the high productivity of web development without the pains of having to support ancient browsers. If your solution wants to beat Electron, it needs to provide a developer environment with the same levels of choice, convenience, productivity, and ease of recruiting engineers.
Extendability and Interoperability
Including Node.js in Electron allows developers to use any of the packages on npm, the largest repository for open source code that ever existed. More importantly, it allows developers to escape the limitations of JavaScript whenever necessary - many Electron applications switch to C++ or Objective-C to write high-performance logic, call out to obscure operating system APIs, or to share code with other environments. Atom recently switched to a native C++ text buffer, Visual Studio Code discovered that optimized JavaScript might be faster for them.
Microsoft often asks me what APIs a solution would need to compete with Electron. The question is flawed: With Electron, one doesn't need to know. Nothing is off-limits, not even the most unknown WinAPI or COM call. Not all Electron apps need to make native calls (like Visual Studio Code's native debugger), but none of them are limited to never making one.
Building, Shipping, Updating
Electron would be a lot less attractive if all users were always running the latest version of their OS, the latest version of a modern browser, and possibly the latest version of your application. We do not live in that world.
Electron offers a platform not just for building an application that works without dependencies on environments that haven't seen updates in more than 10 years, but more importantly, sticks with the developer through the tasks of packaging, shipping, and updating the application.
Browser-focused solutions like PWAs require developers to have an ongoing dialog with their customers about keeping their systems up to date. Native cross-platform solution like Qt tend to consider themselves more a library, less a platform, and have little to offer when it comes to creating auto-updating software, installers, and App Store packages.
You might consider shipping and updating too easy for a cross-platform development solution to concern itself with. If you've never had to build an auto-updater, trust that self-updating software is a tricky beast to control. If you want to defeat Electron, you will have to stick with the developer once the code is written and the app needs to end up on user machines.
Ease of Access & Skills
Looking down on JavaScript developers seems like a quick way for "true developers" to bond together; many assume that Electron developers chose Electron because they wouldn't know how to build an app without it. Yes, Electron makes building desktop applications easy. For cross-platform development, it might be the most accessible solution yet. For myself, the fact that Electron opens up the world of desktop apps to web developers is one of the reasons I'm excited about it.
It is true that the ease of access means that many Electron applications have been written by people who do not fully understand the WinAPI, AppKit, or even how to write performant JavaScript. Expecting those apps to be written natively across all platforms is unrealistic. Prior to Electron, those apps would not have existed at all.
While Electron enables both junior and senior engineers to work together, it's a less crucial factor than often assumed. If another solution beat Electron across all disciplines except in ease of access, companies would switch. If you want to defeat Electron, it is crucial to understand and empathize with the seasoned desktop software engineers who choose it. The engineers behind Visual Studio Code continue to deliver impressive software with equally impressive performance. Suggesting that the team behind Visual Studio couldn't find anyone who understands native Windows development and was forced to use Electron for their installer due to a lack of skills is ridiculous.
Defeating Electron
You'd be surprised how many people deeply involved with Electron would be excited if it didn't need to exist. The path to an obsolete Electron involves a competing technology that offers a better value proposition to junior and senior engineers alike.
If your dream future involves non-cross-platform apps, call upon Apple to care about macOS and development for it. Call upon Microsoft to realize that win32 isn't dead, no matter how hard they're trying to kill it.
Electron isn't here to compete with anyone. It's a free open-source community effort filling a gap. If you want to defeat Electron, you will need to fill it too; and you will need to do a better job than Electron is doing today. Many of the Electron maintainers are here to build desktop apps that end users love. If you succeed in helping them with that difficult task by building a better platform, they will smile, shake your hand, and thank you.