I'm the author of the post and I should also say that I don't love Electron. It's a practical choice for getting an app of the ground, but I want something more lightweight eventually.<p>I see it as a stop-gap until I can invest more resources into something more lean. But I'm focused on the product right now, not rewriting the world and wasting time because of engineering ideals.
The problem I see with many electron applications isn't just that they're bloated (they probably are in about the same relation to average RAM that Tcl/Tk apps were or early Gnome/Mono ones). [Edit: To clarify, I mean the average RAM at the time they were accused of bloat]<p>It's that they're quite non-native. And not just in the "button borders are 1 pixel wider than usual" sense -- they're usually styled to resemble web applications, with big data views, Material UI, etc.<p>Going from this to something more lightweight/native doesn't just require a different API, it requires a completely redesign.<p>In other words: The Big Rewrite That We're Definitely Going To Do Someday(tm).
So, I love the role that Electron fits, but boy do I hate how much we discuss Electron itself.<p>What we should be discussing is providing the functionality of Electron without the cost. A protocol that behaves like React native. Ideally a spec, which any language can implement and provide a native UX to the end user.<p>Some projects try (ProtonNative, for example), but I've not seen one go quite far enough. I don't want to be forced to write a JS app to get benefits here. After all, with ReactNative, it's basically a process RPC to a bunch of widgets. `process <-> UI`. So why be forced to write JS? An open spec would do wonders here.<p>I've not invested cycles on solving this problem, of course. Yet I can't help but wonder why so many people are focused on solving UI issues with very narrow solutions like Electron, ReactNative, ProtonNative and so forth. They're great projects, but a slightly wider vision would make them amazing projects.<p>Thoughts? Am I missing something obvious?
Electron discussions often focus around the battery and memory impact, one other thing I'd mention is the poor access to native features. You get the stuff a web browser can do, but for anything else offered by the OS you might need to wait a while.<p>For example, Apple shipped their first TouchID laptop in 2016, and Electron's support for that landed in v6.0.0 beta 1 just last month.<p><a href="https://electronjs.org/releases/beta?page=2#6.0.0-beta.1" rel="nofollow">https://electronjs.org/releases/beta?page=2#6.0.0-beta.1</a><p>I'd looked at switching off 1password to BitWarden and that's a pretty major feature to be missing for three years.<p>Surprisingly, for as much as everyone craps on the touchbar, that got supported by Electron a lot faster than TouchID did. I guess because not all apps need authentication and they can rely on passwords instead, while it's really obvious when an app doesn't have touchbar support.
If electron apps' claimed memory causes your computer to go slow due to swapping, you should complain. But most complaints I see on this topic stem from a discomfort over the reported figure by the operating system. With SSDs and modern virtual memory systems the claimed memory figure is not a sufficient measure to infer the resource utilization of a process. For example, if slack has a bunch of allocated memory that is rarely accessed, it's going to (at worst) land on your SSD and sit there, having no impact on your user experience.<p>If you want to complain about applications' engineering, you should complain not about claimed memory but about things that are directly affecting resource utilization or user experience like power draw or excessive CPU utilization due to poor programming. Claimed memory must be combined with a profile to show that cold reads are common enough for the claimed memory figure to be correlated with a performance hit. But of course, this often isn't readily available without profiling for all but the most extreme cases, and so engineering types fixate on easily visible measures like claimed memory that likely have no actual resource utilization impact in most cases.
Thanks for the post.<p>> I want something more lightweight eventually<p>Check out <a href="https://github.com/revery-ui/revery" rel="nofollow">https://github.com/revery-ui/revery</a>
Obviously bundling nearly all of Chromium with an app is inherently inefficient, but out of curiosity's sake, has there been any objective analysis of <i>exactly</i> what makes this use a seemingly disproportionate amount of resources? Are JavaScript runtimes inherently inefficient? Is it Electron's node.js part? Is it the huge amounts of code needed to parse and render HTML and CSS? Is it the multimedia features, like WebGL and the video and audio players? Is the problem actually just badly written code running on top of Electron? And if so, what <i>exactly</i> are are most Electron apps doing wrong that one could avoid? Is it, as this blog post seems to suspect, that they aren't sufficiently taking advantage of Electron's node.js integration?<p>In addition, once the actual bottleneck has been identified, doesn't this open the door to fix things on the WebKit/Blink engine side of things? Before, when Electron was managed by GitHub, one could say this would be unreasonably difficult, but now that GitHub is owned by Microsoft, isn't tweaking Blink to be more suitable for deployment environments outside of Chrome exactly the type of thing they would have a vested interest in doing, and the resources to actually pull off? After all, with VS Code, they are one of the highest-profile Electron users, and using Blink in Edge presumably involves working with the Blink code to some degree anyway.<p>It's always struck me that a lot of Electron apps likely never use a single line of WebGL, while a lot of WebGL apps likely only use DOM APIs to pretend the DOM doesn't exist by plastering everything in a huge <canvas> element, and both likely don't want their binaries to include the Chrome devtools, but Electron includes all of these things anyway. I'm not sure how much space or resources it would actually save, but is Chromium/Blink refactoring their code and build process to facilitate Electron building different Electron "profiles" that include different sets of features even remotely a possibility?
Not only memory is the problem with electron, but also app feeling.
Skype left is the only electron app I'm using. And comparing to desktop messaging app (telegram):
1. Skype unresponsive. Opening chat takes up to few seconds.
2. I see how opened chat is literally updating -- messages, avatars, emoticons emerges from dust
3. Selecting messages as messages in native vs selecting messages as text with surrounding artefacts (chat is a html page with all what comes with it)<p>Summarizing, electron apps are just feels like foreigners.
I have never had an issue with electron apps being terrible because of networking - although clearly there are apps that do push more work than is necessary over the network, there’s plenty of native software that does too.<p>My problem with electron apps is that they use way more memory and cpu than they should be - the architecture fix for that would be to not be a full browser.<p>The problem I have is they lack basic app behaviors from the platform. My experience is mostly for the Mac, but my experience using vscode on Linux has been similar.<p>But here we go, for a Mac:<p>* cmd-e/f/g are so wide, not just app wide. Vscode goes even further and seems to achieve per-view behavior.<p>* document editors and viewers are expected to have an icon for the file being edited, either in the window or in the tab. That is a draggable link to the file, and a drop down on right click for the directory hierarchy.<p>* drag and drop of files into and out of the windows don’t work<p>These are basic behaviors that even the simplest apps manage to get right on OS X, yet no electron apps seem capable of meeting this low bar.
People love to bash Electron, but what is the alternative?<p>Is there any other platform that provides:<p>- Support for the 3 major desktop platforms from one code-base;<p>- A decent choice of high-level programming languages (there are excellent compile-to-JS options now);<p>- Reasonable tooling and community support;<p>- MIT (or similar) license
I use VS Code and it never felt sluggish. But it’s probably one of the best Electron apps out there.<p>Honestly, if I had to develop a Desktop app today and wanted it to be cross-platform, I’d probably use Electron. No need for hacky workarounds like in a web app to make it run on every major browser.
I honestly don't know why people waste time building Electron apps.<p>It's the worst possible combination. All of the downsides of web apps (poor performance, memory use, poor integration, etc.) and native apps (security problems, hard to update, etc.), without the advantages of either one.<p>Why would I want to download your specially packaged browser, without adblock or uMatrix or any of that, just to basically view a website anyway?
I've never noticed Electron apps negatively impacting my computer. I use Slack all the time and I don't notice a difference when I have it running vs when i don't. Do most people not like Electron because the number seems high or does it negatively impact their computer in some way? (I have a MBP with 8 gig RAM, that doesn't seem out of the ordinary)
I am an electron hater but this is a really good setup. Server reloading with that debugger is rad. I'm going to use these methods with a platform I don't like.
Well to me it is thing that should not be done at all, instead of doing it diligently.<p>I will put this in category of 'The secret of good user tracking on web', 'the secret of doing quality journalism on ads supported model' or 'the secret of nuanced political debate on Twitter' etc.
The hate for Electron is strong in this thread.<p>For Electron haters, here are the alternatives: OpenJFX (some people hate Java), Qt5 (it can be pricey in some situations), wxWidgets (not popular enough?).<p>However, I have a lot of hope for Flutter in desktop. I hope the developers of Flutter framework can pull off the challenge.<p>In my case, for opensource projects, I definitely use Qt5 (using PySide2). But for proprietary projects, I have to admit that most likely I will choose Electron.
I'm building an application using Electron and I've found the majority of memory consumption occurs when instantiating new components. When using a UI framework like Material, this can happen frequently, such that the simple act of hovering over a menu and showing an indicator can cause an increase of 3 MB of RAM. I love Electron, it allows me to create applications in an intuitive way using a language meant for building UIs, rather than slapping a library on a native codebase, and I can deploy it wherever Chromium is supported, so I'd like to make it efficient, wherever possible.<p>Two solutions I have found during my development:<p>1) Keep your components light. Most of what I used from Material can be done completely with raw HTML and CSS in a simpler fashion without much going on in terms of state, so I created my own components that serve my purposes. A lot of libraries and frameworks are heavy because they are used on webpages viewed by multiple different browsers and require complex logic to work across different environments. Electron sandboxes your code in Chromium + node, you code only for 1 browser engine, so I hope more devs take advantage of that fact.<p>2) Load what you know you need in the beginning, and keep your cache to a minimum. Most Electron apps do not have view transitions, they are built as SPAs. One of the downsides of this is that you need to be mindful of your cache since it is not cleared when you display a new component. Clearing the things that don't matter to the view or data has been essential in keeping my memory footprint small.<p>With a large app that does many things and loads many views, I'm able to keep the RAM usage to under 200, most times around 150, which, while larger than something like Excel running idle, is a small price to pay to have intuitive design features and access to a large and constantly growing library of reusable components and packages.
The type of developer that chooses Electron isn't going to care about squeezing out the best performance possible. They already made a conscious trade-off to sacrifice performance and memory usage in exchange for productivity. They won't do some hacky things like use Rust instead of nodejs.
It sounds like a generally good approach for keeping the UI process responsive at all times. I wonder if the serialization cost behind all those IPC calls becomes an issue at some point, especially when passing large structures back and forth, have you found this to be an issue for your use case?
I feel like the key idea here is somewhat unrelated to writing Electron apps. It's that you can set up any Node server app to run inside an Electron window during development and then you get cmd+r and all the devtools for free. Kind of like a node inspector on steroids. Pretty nifty!
If you need a background process to call Node APIs because "it's the only place where it's safe to access them", what unsafe way is this meant to contrast with? Does Electron normally (but unsafely?) call Node APIs from the browser process?
Thanks for sharing! Your post is full of things that might seem obvious in hindsight, but all too likely to be ignored absent a compelling writeup like yours. Bookmarked the linked repo, will revisit w/ my next Electron app.
I made something similar a couple years ago: <a href="https://github.com/smith-kyle/electron-process" rel="nofollow">https://github.com/smith-kyle/electron-process</a><p>But I love the addition of defaulting to a node server for lower memory usage.<p>The Atom editor (the first Electron app) has slowly been rewriting a lot of their modules in C++ for speed and lower memory usage, binding to them through NodeJs. Kind of ironic since GitHub created Electron to build desktop apps using web technologies.
Vote for Linux support in Actual here:<p><a href="https://trello.com/c/A7XzJgJX" rel="nofollow">https://trello.com/c/A7XzJgJX</a>
IMHO, good electron apps feel and behave like native apps. Or, in the worst case scenario, they feel like an equivalent web app.<p>Specifically - I should not have to think of having to “ctrl-R” for a desktop application.<p>Good electron apps do exist, but they feel like a vast minority. Most just feel like a bloated version of their web application.
My simple rule of thumb for reducing the memory usage of Electron apps is to not run any of them. Problem solved. It's like why I never ever installed java which was subpar garbage. Gosling has a lot to answer for.
I find the problem lies with the trade-off you are making.<p>You are making your life as a developer easier in exchange massively increasing the resource requirements and battery usage on end-user machines.<p>It's just bad practice and Electron encourages it.<p>I feel like if we ever want to be taken seriously as a profession the way structural or mechanical engineers are for example, then efficiency and reliability need to be primary considerations, otherwise we are basically making toys.
Some people seem to think that unused ram is good, quite the contrary actually. If you have 50 of these apps running doing work while playing a game while having a pc from 10 years ago, then I can actually see a problem. Laptop and battery-driven devices is a whole other matter though.<p>I like to think the reusability and speed of development with electron is just terrific and is a trade-off that is worth it in the end.