Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Why / Why Not Use Electron?
12 points by mc42 on July 19, 2016 | hide | past | favorite | 21 comments
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?

Why not:

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.


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 personally love it. I've only written a couple of small, really simple apps, but I've got a couple more under way. To me, the idea of writing desktop, native apps, utilizing the web development technologies I already know, is bad ASS. the sizes are on the high side for some things, sure, but that's not really a HUGE deal breaker for me.

I agree, our users don't care about a 50mb download - they love the native feel of our app.

I dislike Electron apps that I use because they're incredibly bloated. I don't know if that's always a guarantee with Electron.

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.

Performance surely depends on many factors. In my experience, VS Code for big Unity C# projects on OS X slows down a lot soon after launching the editor, and all the OmniSharp/IntelliSense things become unusable. Even in that case, the editor UI itself remains very responsive, so maybe it's the omnisharp implementation to blame, since it can take 15-20s for simple code completion to show up. The latest VS Code updates have tried to address some of the performance issues, but still have not solved all of them. What's more, one of its recent issues was 'Electron Helper' process hogging nearly 100% CPU usage, which might have given the idea that Electron is the culprit.

Bigger drawback is that it's bloaty, I have a mix of Chrome apps and Electron apps, the Electron are big (40+ MB) and take much longer to start because they have their own Chrome to open, while the Chrome apps just use the global Chrome instance that's already open.

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.

Well but what about those people who do not even have Chrome installed and are not even planning to use Chrome for privacy reasons?

I'm not saying "just install Chrome", that wouldn't solve the problem. I'm saying it'd be nice just have a Chromium install that's used by the other apps. If you use anything based on Electron you're using Chromium anyway.

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.

Pro Simple to build, cross-platform - even linux supported.

Con The default electron build is quite large, typically >50mb for a single page app.

Something I have always wondered.

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++.


- 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.

[1] https://github.com/node-ffi/node-ffi

[2] http://www.swig.org/

Being totally honest, I have very little experience when it comes to designing desktop apps. Most of my experience in UI development has been in either Swing (ew) or Qt/C++ (slightly less ew, but still ew).

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.

> we could wrap our web-based portals in "desktop-y" apps and get rid of the web browser entirely

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.

I totally agree! Hence why I gave it special exception.

Why not use React native? Putting a browser inside your mobile or desktop app is always going to be bloated and slow compared to using JavaScript to drive native views.

(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.)

React Native is for mobile, whereas Electron is for desktop. They're not substitutes for one another.

Well, there is react-native-desktop for macOS...


But that's me being pedantic.

react-native-desktop is what I was thinking of when I wrote my original post. I think it's a matter of time before there's a Windows version.

Also available from Microsoft: https://github.com/ReactWindows/react-native-windows

Seems to be only Windows 10 and xbox though.

Can Facebook be trusted to properly run this and not drive it against a wall soon enough?

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact