Summarizer

Electron and Memory Bloat

Criticism of electron apps consuming 300MB+ RAM, hopes that shortages will force software optimization, debate over cross-platform development tradeoffs versus efficiency

← Back to The RAM shortage could last years

The debate over Electron's notorious memory bloat highlights a sharp divide between users demanding efficiency and developers who prioritize the cross-platform speed and design flexibility of the web stack. Critics argue that shipping an entire browser for simple tasks is a wasteful "skill issue," expressing hope that hardware constraints will finally push the industry toward lean, native alternatives or emerging Rust-based tools like Zed. Conversely, proponents contend that the unmatched ergonomics of HTML and CSS allow for sophisticated UI designs that are far more difficult to replicate in native environments, making the high RAM cost a necessary trade-off for modern software delivery. Ultimately, this tug-of-war underscores a fundamental tension in software engineering: whether to prioritize the conservation of the user's system resources or the optimization of the developer's time and talent.

48 comments tagged with this topic

View on HN · Topics
I’m a bit of an optimist. I think this will smack the hands of developers who don’t manage RAM well and future apps will necessarily be more memory-efficient.
View on HN · Topics
> I think this will smack the hands of developers who don’t manage RAM well And hopefully kill Electron. I have never seen the point of spinning up a 300+Mb app just to display something that ought to need only 500Kb to paint onto the screen.
View on HN · Topics
Hopefully just kill off the javascript for everything mindset to be honest.
View on HN · Topics
It's happening. Cursor 3 moved to rust. A lot of people are using Zed (rust) instead of vscode.
View on HN · Topics
It won't be "happening" until Slack, Teams, and Discord leave Electron behind. They are the apps that need to be open 24/7.
View on HN · Topics
It's not entirely clear what the connection is. We're not doing Electron because some popular software also using it. We're doing Electron because the ability to create truly cross-platform interfaces with the web stack is more important to us than 300 MB of user memory.
View on HN · Topics
> We're doing Electron because the ability to create truly cross-platform interfaces with the web stack is more important to us than 300 MB of user memory. It's closer to 1GB but trust me, everyone is well aware of your priorities.
View on HN · Topics
> web stack is more important to us than 300 MB of user memory. May I never have to use or work on your project's software.
View on HN · Topics
"I would rather spend the user's money than my engineer's time"
View on HN · Topics
Teams works similarly in browser tab and "natively". Slack was similar if I remember correctly.
View on HN · Topics
You should check the memory use of that browser tab. You’re not saving much either way running in a browser or in Electron, which is effectively a browser.
View on HN · Topics
I only ever use Discord in a browser window.
View on HN · Topics
Are you sure about Cursor? I haven't seen anything about that, I think it's still based on VSCode/electron.
View on HN · Topics
"cursor 3" is just a landing page. The editor is still the old vscode fork...
View on HN · Topics
As if native apps are any better. Books app on my mac takes 400MB without even having a single book open.
View on HN · Topics
I find that an exaggerated claim, have you really checked they aren't using a webview or some other non-native runtime?
View on HN · Topics
The point is being able to write it once with web developers instead of writing it a minimum of twice (Windows and macOS) with much harder to hire native UI developers.
View on HN · Topics
And HTML/CSS/JS are far more powerful for designing than any of SwiftUI/IB on Apple, Jetpack/XML on Android, or WPF/WinUI on Windows, leaving aside that this is what designers, design platforms and AI models already work best with. Even if all the major OSes converged on one solution, it still wouldn't compete on ergonomics or declarative power for designing.
View on HN · Topics
Lol SwiftUI/Jetpack/WPF aren’t design tools, they’re for writing native UI code. They’re simply not the right tool for building mockups. I don’t see how design workflows matter in the conversation about cross-platform vs native and RAM efficiency since designers can always write their mockups in HTML/CSS/JS in isolation whenever they like and with any tool of their choice. You could even use purely GUI-based approaches like Figma or Sketch or any photo/vector editor, just tapping buttons and not writing a single line of web frontend code.
View on HN · Topics
Who said anything about mockups? Design goes all the way from concept to real-world. If a designer can specify declaratively how that will look, feel, and animate, that's far better than a developer taking a mockup and trying their hardest to approximate some storyboards. Even as a developer working against mockups, I can move much faster with HTML/CSS than I can with native, and I'm well experienced at both (yes, that includes every tech I mentioned). With native, I either have to compromise on the vision, or I have to spend a long time fighting the system to make it happen (...and even then)
View on HN · Topics
well, then you are really bad at native and should not be comparing those technologies despite your claims otherwise (which make little sense).
View on HN · Topics
> really bad at native Yikes. I spent 15 years developing native on both mobile and desktop. If you think that native has the same design flexibility as HTML/CSS, you're objectively wrong. By design, each operation system limits you to their particular design language, and styling of components is hidden by the API making forward-compatible customisation impossible. There's no escaping that. And if you acknowledge that fact, you can't then claim native has the same design flexibility as HTML/CSS. If you don't acknowledge that fact, you're unhinged from reality. There's pros and cons to the two approaches, of course. But that's not what's being debated here.
View on HN · Topics
The real disconnect is that the user doesn't really care all that much. It's mostly the designers who care. And Qt for example but also WPF let you style components almost to unrecognizable and unusable results. So if everyone will need to make do with 8GB for the foreseeable future, designers might just be told "No.", which admittedly will be a big shock to some of them. Or maybe someone finally figures out how to do HTML+CSS in a couple of megabytes.
View on HN · Topics
There is native to the OS and there's native to the machine. Anyways, I'm both cases you don't really have to write it twice. Native to the OS: write only the UI twice, but implement the Core in Rust. Native to the machine: Write it only once, e.g. in iced, and compile it for every Plattform.
View on HN · Topics
You mean the point is to dump it all on the end user's machine, hogging its resources. It's bad enough having to run one boated browser, now we have to run multiples? This is not the right path.
View on HN · Topics
As the kids say: skill issue!
View on HN · Topics
The point is you can be lazy and write the app in html and js. Then you dont need to write c, even though c syntax is similar to js syntax and most gui apps wont require needing advanced c features if the gui framework is generous enough. Now that everyone who cant be bothered, vibe codes, and electron apps are the overevangelized norm… People will probably not even worry about writing js and electron will be here to stay. The only way out is to evangelize something else. Like how half the websites have giant in your face cookie banners and half have minimalist banners. The experience will still suck for the end user because the dev doesnt care and neither do the business leaders.
View on HN · Topics
Syntax ain't the problem. The semantics of C and JS could not be more different.
View on HN · Topics
But the point isn’t that they’re more different than alike. The point is that learning c is not really that hard it’s just that corporations don’t want you building apps with a stack they don’t control. If a js dev really wanted to it wouldn’t be a huge uphill climb to code a c app because the syntax and concepts are similar enough.
View on HN · Topics
Honestly C and JavaScript could hardly be more different, as languages. About the only thing they share is curly braces.
View on HN · Topics
Yeah JS is closer to lisp/scheme than C (I say this as someone who writes JS, Clojure and the occasional C).
View on HN · Topics
What "advanced features" are there to speak of in C? What does the syntax of C being similar to JS matter? This comment makes no sense.
View on HN · Topics
Well theres the whole c89 vs c99. I’ll let you figure the rest out since it’s a puzzle in your perspective.
View on HN · Topics
You do need a couple framebuffers, but for the most part yeah...
View on HN · Topics
Who cares about 300Mb, where is that going to move the needle for you? And if the alternative is a memory-unsafe language then 300Mb is a price more than worth paying. Likewise if the alternative is the app never getting started, or being single-platform-only, because the available build systems suck too bad. There ought to be a short one-liner that anyone can run to get easily installable "binaries" for their PyQt app for all major platforms. But there isn't, you have to dig up some blog post with 3 config files and a 10 argument incantation and follow it (and every blog post has a different one) when you just wanted to spend 10 minutes writing some code to solve your problem (which is how every good program gets started). So we're stuck with Electron.
View on HN · Topics
> And if the alternative is a memory-unsafe language and if not?
View on HN · Topics
> and if not? If the alternative is memory-safe and easy to build, then maybe people will switch. But until it is it's irresponsible to even try to get them to do so.
View on HN · Topics
Until? Just take what's out there - it's so easy to improve on Electron
View on HN · Topics
Like what? Where else (that's a name brand platform and not, like, some obscure blog post's cobbled-together thing) can I start a project, push one button, and get binaries for all major platforms? Until you solve that people will keep using Electron.
View on HN · Topics
There are quite a few options. Many of them look dated though. I think that's the usp of electron.
View on HN · Topics
There's a world of difference between using a memory safe language and shipping a web browser with your app. I'm pretty sure Avalonia, JavaFX, and Wails would all be much leaner than electron.
View on HN · Topics
The people who hate Electron hate JavaFX just as much if not more, and I'm not sure it would even use less memory. And while the build experience isn't awful, it's still a significant amount of work to package up in "executable" form especially for a platform different from what you're building on, or was until a couple of years ago. And I'm pretty sure Avalonia is even worse.
View on HN · Topics
> and I'm not sure it would even use less memory It likely would use less, and doesn't use a browser for rendering. > And I'm pretty sure Avalonia is even worse Definitely not > The people who hate Electron hate JavaFX just as much if not more In my opinion, I only see this from people that seem to form all of their opinions on tech forums and think Java=Bad. These are the people that think .NET is still windows only and post FUD because they don't know how to just ask for help.
View on HN · Topics
I don't understand how this connects to your original claim, which was about trading ram usage for CPU cycles. Could you elaborate? From what I understand, increasing cache locality is orthogonal to how much RAM an app is using. It just lets the CPU get cache hits more often, so it only relates to throughout. That might technically offload work to the CPU, but that's work the CPU is actually good at. We want to offload that. In the case of Electron apps, they use a lot of RAM and that's not to spare the CPU
View on HN · Topics
Or just using less electron and writing less shit code.
View on HN · Topics
I said it for many years that OS developers need to focus on over optimisations. If it wasnt a chip sgortage it would be the ever slowing progress on chip scaling. But software optimisation helps all hardware and that doesnt drive sales. Linux however, they dont have to worry about that. Maybe it is finally the era of Haiku OS as the ghost of BeOS rises!
View on HN · Topics
There is almost no way any hyper optimized OS could protect you from Windsurf re-layouting the whole UI 60 times per second because of badly implemented spinner, and taking 8 GB of RAM to show it.
View on HN · Topics
I wonder if this might motivate to write more memory efficient software. I mean we have so much memory, but even some trivial programs eat hundreds of megabytes of ram.