Ask HN: Why / Why Not Use Electron?
More and more apps that I've seen published here are heavily disliked for their usage of Electron. What experiences have you had with Electron and why / why isn't it a good idea to write an application with it?
In my experience, Electron apps tend to be bloated, not very performant and/or energy inefficient. This means that developers make a choice regarding users' disk space, user experience and battery life. The extent to which users notice any of this is of course dependent on a combination of their machine (e.g. old/new hardware, laptop/desktop) and the application being run.
Also, since you don't use the platform's native widgets, there's poor (or nonexistent?) accessibility features for users with special needs - not to mention the implications (HCI-wise) of redefining/replacing standard interface elements.
In my opinion, all this reeks of poor design, and is arguably (in some cases) downright user-hostile and unethical.
To portray it as "native" is, frankly, ridiculous.
Why:
The main thing Electron does well is lower the barrier to entry and maybe increase development speed.
I can definitely see use cases, such as quick prototypes and internal applications. And it is cross-platform. There's probably other good reasons to use it as well.
I've seen people criticize Electron for being slow/unresponsive, but VS Code is incredibly fast and responsive, so I know for a fact that Electron usage doesn't guarantee slowness.
I wonder if we'll someday get something akin to the JVM for Chromium-based stuff. We'd finally have a single install that could be updated and every app being kilobytes instead of megabytes.
It's not about installing an additional browser, it's about unififying all the Chromium installs in a single package. Imagine how nice would it be if every Java app had its own copy of the JVM: They would be incredibly bulky and near impossible to update (considering the sort of vulnerabilities that the JVM gets, it would be a disaster). It's a scenario for JVM, it's a reality for Electron.
Con The default electron build is quite large, typically >50mb for a single page app.
The first version of firefox was 5 mb and chrome was 9 mb or so. Can't we bundle such a light version of the browser, instead of always bundling the latest and greatest? Shouldn't it be enough to render the gui's of native apps?
- Productivity: The browser renderer and Node (as well as the open source ecosystems that accompany those environments) offer you a lot. HTML, CSS and JS are relatively easy and because there are a lot of web programmers out there, your access to developers, developer resources and libraries is vast.
- One portable target: Develop your app for multiple operating systems without worrying about many of the problems inherent in web programming (ES6 support, CSS inconsistencies between browsers, etc.) or cross platform development (compilation, dynamic linking, header / include guards, etc.)
- Decent OS integration: Interacting with filesystem, native OS menu bars, notifications, etc. is fairly simple.
- Multiple language support: Electron uses JavaScript for application logic but you could alternatively use CoffeeScript, TypeScript, ClojureScript, Elm or any language that can compile to JS.
- Performance when you need it: Use something like node-ffi [1] or SWIG [2] if you need C or C++.
Cons:
- Memory usage: An Electron app is essentially a fully-featured Chromium browser and a Node process that communicate via IPC. This might be a bit bloated for some applications, particularly if you're targeting systems where memory is limited.
- Large builds: Packaged Electron apps contain everything they need to run so they're typically quite large. Don't be surprised if your "hello world" app ends up being over 30MB.
- Not truly native: Sure, you can make your app look great but the only way you can make it look 100% "native" is to use the widget toolkits of whatever operating systems you're targeting. Electron does not give you access to this.
- The DOM can be your worst enemy: This is where the performance issues of many Electron apps (Atom comes to mind) arise. Depending on the complexity of your app, you'll want to either limit how many elements you render to the page at any given moment or look into using something like HTML5 canvas to render.
- Single threaded: Node is single threaded. If true concurrency is important to you, you might consider another platform.
Overall, I love Electron. It's not the right choice for all applications but if you have experience developing for the web and want a desktop application platform that is easy to get into, I'd give it a shot.
I kind of hate the idea of Electron, and this is for a variety of reasons:
* I think Javascript is a terrible language. * I think HTML/CSS is a terrible language. * I think the web is too bloated as it is, and extending that paradigm to the desktop only encourages more lazy, bloated development.
That being said, I get the appeal Electron has for a lot of people. If you already know web development, then writing a desktop app becomes a no brainer. If you're already a destkop UI guy, you can learn Electron and be a web front end guy too. All good things.
But the idea of using a fucking gigantic framework (I mean think about it, just Electron by itself is all of Chromium basically, or at least the big complicated exciting bits) is a massive code smell to me. It's like using an ORM or a heavyweight web framework: whenever you're leaning on that much code just for your baseline of functionality, you're making a lot of assumptions that should, as a developer, at least give you pause. One of the things I love about Swing is that I can spin up a basic prototype in a couple hours with just a couple hundred lines of <insert non-java JVM language here>. And besides the built-in language UI framework, I own every piece of that code and can tell you what it all does. I feel like web development (an by extension, Electron) doesn't have any of those desirable attributes.
Web development often involves hundreds of lines of boilerplate, the import of a several-thousand line Javascript API, a heavy CSS framework like bootstrap (for prototyping, at least), and the assumption that the magic will all just work. I know that fundamentally there isn't that much difference between writing an app in Swing versus Electron if we're talking about complexity, nor is there that much difference in performance for simple cases. But it just feels better for me if all I'm doing is a few API calls (even if the underlying code is similarly complex).
Now, there is one exception to all of this: one of the apps someone on my team supports at work is our monitoring dashboard/customer service portal. Because of some bizzar-o rule from up top, we aren't allowed installing anything except for absolutely essential apps on the support machines. Electron proved to be a lifesaver here because we could wrap our web-based portals in "desktop-y" apps and get rid of the web browser entirely. For cases like that (or like a friend of mine, who is currently working on medical instrument displays and uses JS/Electron in a couple of experimental projects because it's easier than Qt and the machines run Linux or Windows 7 anyway) where really what you need is a website, wrapped in a clean sandboxed container, I can kind of understand its niche.
This is by far the most powerful 'feature' of Electron, to take a largely already written webapp and insta-package it into a cross-platform desktop application.
(Users might not notice that bloat and slowness if they're on a desktop system with a fast CPU and lots of RAM, which is one reason why Electron seems okay in certain cases.)
https://github.com/ptmt/react-native-desktop
But that's me being pedantic.
Seems to be only Windows 10 and xbox though.