I always get a chuckle at all the hate Electron gets on HN, or in very technical communities. At the end of the day, so many people fail to realize the success of Electron is in making desktop applications so much more approachable for those that are mainly front-end focused developers/hackers.<p>I have played around with Electron in the past for fun "nothing" projects, and also tried to understand what many on HN would want as the "correct" way to build native apps. It's an indescribable difference how much easier Electron is to get up and running from my experience, as someone who primarily does front-end work.<p>Are there better ways to build native apps? Of course. Electron still solves a massive problem for many developers and end-users that I don't understand why so many here get on their high horse refusing to acknowledge. It's similar to PHP hate to me. Of course there are better languages to use, but things like WordPress using PHP are so much more approachable for so many developers.
Sorry, but no. Electron is the absolute worst piece of technology that I have come across in at least the last 20 years. It's not only that it is bloated, ridiculously resource hungry and terribly inconsistent because every program has it's own set of UI controls, but it's also just absolutely plain terrible to work with:<p>The APIs are a complete mess, half of them are not working properly, things constantly get broken between even minor version revisions, the documentation is usually outdated and incorrect and you need to plaster your code with OS-specific if-else statements <i>all over the place</i> because many of Electron's APIs behave differently on different OSes. The whole thing is just a complete disaster.
Fair points on downsides and upsides of using Electron in development. But there's huge gaping hole in this logic: the points are given from the perspective of software developers, not software users. Users, given the choice between native and Electron, would overwhelmingly choose the former.<p>Speaking as a user I don’t care about your production costs and your programming knowledge. I care about my experiences. That’s why many Electron-based programs are marketed to managers as “solutions”, not to the actual end users.<p>As a macOS user let me add to the list of complaints mentioned by the author. Despite having fully functioning native iOS apps, some companies will not allow installing those directly on M1 based Macs, nor would they produce a rather simple ports for macOS. They will insist for you to use Electron-based client, like everyone else does. Teams, Slack, Discord. So I do agree that at least in this case Electron is evil.
I made a couple of basic CRUD apps with it and it was pretty cool. I could build a React app and then build the electron app based on React's build folder and it just works.<p>I'm still working on learning C++/something like QT but I was able to deploy an app to Win/Lin/App.<p>For reference<p>Cross platform CRUD app (desktop, Android RN app)
<a href="https://github.com/jdc-cunningham/cross-platform-app" rel="nofollow">https://github.com/jdc-cunningham/cross-platform-app</a><p>Basic news slider app but it was transparent
<a href="https://github.com/jdc-cunningham/frameless-electron-news-reader-desktop-app" rel="nofollow">https://github.com/jdc-cunningham/frameless-electron-news-re...</a>
A lot of people hate electron but frankly, it's the future of desktop applications and probably the future of mobile applications. The browser is currently the best implementation of a true cross platform framework. People complain about nebulous concepts like "bloat" but I think fragmentation across platforms is just as if not more harmful and bad. For mobile for example, I exclusively build native iOS apps because the ecosystem is superior and I simply do not have the bandwidth as an individual to maintain software for 3 unique platforms (web, iOS, and Android) so I just don't build Android apps because the android market is just not valuable.<p>Also as a user of many electron based apps, I currently use apple silicon native electron apps on my m1 macbook air and they are extremely snappy with only 16gb of ram (go download the canary version of discord which is compiled to apple silicon if you want to see the difference). If there is one entity that I'm truly angry at it is intel for completely mishandling and holding back the desktop processor ecosystem for the past decade (or longer).
> There might be a chance to dynamically link the LGPL version and avoid paying for the complete license, but that’s not always possible.<p>This is such FUD. The normal way to use Qt is dynamically linked, it is not difficult to use the LGPL version, you most likely don't use the premium features, and the restrictions are about using Qt to create embedded devices.<p>There are good reasons not to use Qt, like that many teams don't have the discipline to maintain a large C++ gui application. There are plenty of crap broken Qt apps because it is easy to screw up. There are few responsive electron apps because it is difficult to make fast.<p>Easier to make a mediocre app in electron -> classic worse is better in action.
As of sizes ...<p>For Sciter Quark ( <a href="https://quark.sciter.com" rel="nofollow">https://quark.sciter.com</a> ) I've measured size of minimal "Hello World".<p>- Electron: 50 MB on disk, 200 MB of RAM and at least 2 processes running.<p>- QT: 5 MB (and 30 MB if + QtWebKit) and ~70 MB (200 MB if QtWebKit) of RAM.<p>- Sciter Quark (standalone Sciter executable): 5 MB on disk, 32 MB in RAM. That includes HTML/CSS UI, JS engine, NodeJS alike runtime.<p>Out of the box Sciter works on same platforms as Electron.
If it didn't say "Electron" in the title, I'd have thought he was describing Java. I don't see why Electron itself is a necessary evil - Java has been able to do all of this (just as badly) for over 20 years.
I would definitely recommend the author look at Flutter again now. The comment there was back in July. The desktop experience has greatly improved. I have been building out a desktop-first set of components and it's been a real joy to work with.
<i>"Did you notice that most desktop apps that feel snappy don’t include any animation?"</i><p>well, this is patently false. <a href="https://developer.apple.com/design/human-interface-guidelines/macos/visual-design/animation/" rel="nofollow">https://developer.apple.com/design/human-interface-guideline...</a>
The problem with Electron is that it shouldn't be necessary. We all already have web browsers installed. Why does each application need to bundle its own? Because browser vendors refuse to provide useful APIs?
I wish writers would stop using overdone intros like this<p>"Unless you’ve been living under a rock for the past 5 years..."<p>I see this sort of thing and I just want to stop reading. Only worse is<p>"This isn't your father's..."
My major annoyance with Electron is every app shipping its own version of it, particularly on Linux where most distros tend to ship electron in the repositories. I'd really rather not have 5 different chromium versions - that are lacking security updates - on my system. I wish packagers were more aggressive about not bundling them.
I love how he takes a huge, highly custom (custom widgets and things everywhere) and unoptimized Qt application (Telegram Desktop), that as of late has started shipping with a version of WebKit for some functionality related to payments, without mentioning it's unreasonably huge for a Qt application. Apps like qbittorrent are a third of its size, and this is not mentioning that platforms like linux have Qt installed as a system-wide library, making the whole size comparison moot. (you cannot install and use a system-wide version of electron for most electron apps).<p>He also fails to consider that there's bindings for all native platform UIs for a ton of languages. You could write gtk code in javascript or C# if you wanted, and this is especially relevant when mentioning WxWidgets. You don't have to write your business logic in C++ these days.
As an amateur programmer, it really does feel like Electron would be one of those things that's absolutely garbage except for literally everything else which is even worse.<p>I am able to do and automate all sorts of very cool and amazing things that wow friends and family, mostly through bash as well as some Python.<p>And then there's GUIs. It makes no sense that they are this hard to program. If it's the tiniest bit more complex than something that can be done with Zenity, it's probably not going to happen. Nothing comes close to being as easy as some web-type GUI, which aren't themselves that easy.
Electron exists because cross platform native desktop development is a terrible experience, and many developers (some who even frequent HN!) prefer going with the easy and fast route (due to a variety of pressures) over the native route.<p>It’s the same reason why people gravitate towards MIT and Apache licenses over things like lGPL. It doesn’t require a developer to think as hard if they are in violation of the license with their project. Though plenty of developers still screw this up even with those licenses (see the devs of sonic colors ultimate and the violation of the Godot Engine’s MIT license)
Great article. It starts by setting forth a good basis, that I think covers almost all of the primary Electron complaints. There's a very outraged comment decrying these plus also a difficult messy dev story[1], but generally I think the article starts by outlining the criticism fairly well.<p>After enumerating the problems with Electron, the article outlines a wide range of alternatives. This is such a great exploration! I love love love for example the idea of localhost http servers. The article discusses them! I feel differently than the author, but great & honest review:<p>> <i>I know this is highly subjective, but I really appreciate having a separate window for each application, along with good OS integrations such as native menu bars and dialogs.</i><p>Covering up & coming webview embedders like Tauri really won me over. The author showed a deep & expansive knowledge of up & coming alternatives, that still make use of the wonderful great web platform so many folks know & enjoy:<p>> <i>Many projects are trying to overcome Electron’s drawbacks using this approach, such as Electrino, webview, Tauri, and many more.</i><p>And it highlights that these alternatives still lack a lot of standard native integration, that it's not yet baked in anywhere near as well as Electron does:<p>> <i>You see, if you choose this approach, you will need to do a lot of “plumbing” yourself, as you don’t have access to any of the convenient APIs exposed by Electron. Do you want a menu bar? You have to write the low-level bindings yourself, often multiple times depending on the number of platforms you are looking to support.</i><p>I'm hoping some of these up & comers continue to advance, continue to make inroads. Electron has been 100% a magic bullet for countless great apps, big and small. Is it 100% painless? No. But it's pretty damned good, and it marries good UX development to the power & capabilities of server-side technology, in pretty excellently & unique cross-platform way, and that's a really great combination.<p>[1] <a href="https://news.ycombinator.com/item?id=29420450" rel="nofollow">https://news.ycombinator.com/item?id=29420450</a>
Most software today is bad, Electron is worse. Tolerating such concepts leads to mainstream software abominations like the Epic Games Launcher. In a world ever so dependent on technology.
> Code once, deploy on Windows, macOS, and Linux<p>This is a major pain point of electron. Sure you can save some costs, as you only have to write one GUI, but the result is always really bad.<p>The only electron application that is even remotely usable is VSCodium. MS Teams is a slow dumpsterfire and a mess of UI (Why do they even implement own "Close Window" buttons?)<p>Furthermore it is simply annoying if an application does not look like the rest of my desktop
I worked on a cross-platform C# application that ran on both Mac and Windows. I really liked the language and most of the experience. The biggest problem was that the C# toolchain was very glitchy on Mac. (I did have to write shims in C so that Objective C could call into C#.)<p>In our case, C# was the right choice because of what the application did. (There was no way we could be web based.) For many applications, Electron (or similar) is the right choice.<p>We did have two native UIs: WPF and Cocoa. The Mac developers eventually figured out how to use C# models and controllers from Objective C.<p>Again, I would only recommend such an approach if you need close integration with the UI. We had tray/taskbar icons, filesystem watchers, drivers... Things that really don't make sense to do in something like Electron.<p>I'd also like to point out one advantage of Electron, if you can do it: Garbage collection. I personally find memory management in C/C++/Rust a chore, so if Electron is "good enough," you get all the advantages of V8's garbage collector.
Hopefully, we'll start more commonly getting the benefits of Electron in a leaner package as with Tauri[1] or Wails[2]<p>[1] <a href="https://tauri.studio/en/" rel="nofollow">https://tauri.studio/en/</a>
[2] <a href="https://wails.io" rel="nofollow">https://wails.io</a>
Some sample experiences:<p>At my workplace I'm using Electron to build a data heavy application (bill of material, 3D visualization). Performance is spectacular, especially 3D visualization of very large models (threejs). I'm using agGrid for the tables. Also extremly fast and powerful.<p>The users don't care <i>at all</i> that the app is 93 MB and takes 3-5 seconds to start. They love the app for the performance, features and ease of use. I consider Electron as a great success in this case.<p>I'm using VS Code, Obsidian and Todoist daily. I love them and don't care that they're Electron apps.
I get the feeling that we could all just copy and paste our comments from the last Electron post.<p>I doubt anyone is going to chance their mind about it. It is the jQuery of cross-platform development.
I think the hidden reason many hate Electron is because they are forced to use software written in Electron by the choice of their companies. For example I'm forced to use Teams at work but I don't even have Teams on my personal laptop.
Simply, a lot of software that makes people's lives easier wouldn't exist without Electron. So yes, Electron is good.<p>The same amount of effort spent in Electron wouldn't get you a better native app. It would more likely get you no app.
<p><pre><code> Unless you’ve been living under a rock for
the past 5 years,chances are you have used
an Electron-based application at least once
in your life.
</code></pre>
What does it mean to "live under a rock"?<p>I have never used an Electron app because all my needs are covered by termial applications, Firefox, LibreOffice and Gimp.<p>Which rock do I live under?
The main computing constraint isn't the hardware that the software is running on, but is instead the wetware that creates the software<p>npm install --save electron