I wouldn't bet on an Electron app winning anything long-term in the dev-oriented space.
Firstly, the barrier to entry lower for people to take web experience and create extensions, furthering the ecosystem moat for Electron-based IDEs.
Even more importantly, though, the more we move towards "I'm supervising a fleet of 50+ concurrent AI agents developing code on separate branches" the more the notion of the IDE starts to look like something you want to be able to launch in an unconfigured cloud-based environment, where I can send a link to my PM who can open exactly what I'm seeing in a web browser to unblock that PR on the unanswered spec question.
Sure, there's a world where everyone in every company uses Zed or similar, all the way up to the C-suite.
But it's far more likely that web technologies become the things that break down bottlenecks to AI-speed innovation, and if that's the case, IDEs built with an eye towards being portable to web environments (including their entire extension ecosystems) become unbeatable.
The last thing I want is to install dozens of JS extensions written by people who crossed that lower barrier. Most of them will probably be vibe coded as well. Browser extensions are not the reason I use specific browsers. In fact, I currently have 4 browser extensions installed, one of which I wrote myself. So the idea that JS extensions will be a net benefit for an IDE is the wrong way of looking at it.
Besides, IDEs don't "win" by having more users. The opposite could be argued, actually. There are plenty of editors and IDEs that don't have as many users as the more popular ones, yet still have an enthusiastic and dedicated community around them.
The most successful IDE of all time is ed, which is enthusiastically used by one ancient graybeard who is constantly complaining about the kids these days.
Nobody has told him that the rest of the world uses 250MB of RAM for their text editor because they value petty things like "usability" over purity. He would have a heart attack - the last time he heard someone describe the concept of Emacs plugins he flew into a rage and tried to organize a death panel for anyone using syntax highlighting.
People dunk on VS Code but it’s pretty damn good. Surely the best Electron app? I’m sure if you are heavily into EMACS it’s great but most people don’t want to invest huge amounts of time into their tools, they would rather be spending that time producing.
For a feature rich workhorse that you can use for developing almost anything straight out of the box, it within minutes after installing a few plugins, it’s very hard to beat. In my opinion lot of the hate is pure cope from people who have probably never really used it.
It’s part of the furniture at this point, for better or worse. Maybe don’t bet on it, but certainly wouldn’t be smart to bet against it, either.
JetBrains, Visual Studio, Eclipse, Netbeans…
VS Code does well with performance. Maybe one of the new ones usurps, but I wouldn’t put my money on it.
VSCode has even less features than Emacs, OOTB. Complaining about full IDEs slowness is fully irrelevant here. Full IDEs provide an end to end experience in implementing a project. Whatever you need, it's there. I think the only plugins I've installed on Jetbrains's ones is IdeaVim and I've never needed something else for XCode.
It's like complaining about a factory's assembly line, saying it's not as portable as the set of tools in your pelican case.
No way that is true. In fact, it's the opposite, which is the exact reason I use VS Code.
VSCode is more popular, which makes it easy to find extensions. But you don’t see those in the Emacs world because the equivalent is a few lines of config.
So what you will see are more like meta-extensions. Something that either solve a whole class of problems, could be a full app, or provides a whole interaction model.
I've used Emacs.
> But you don’t see those in the Emacs world because the equivalent is a few lines of config.
That is really quite false. It's a common sentiment that people spend their lives in their .emacs file. The exact reason I left Emacs was that getting a remote development setup was incredibly fragile and meant I was spending all this time in .emacs only to get substandard results. The worst you do in VS Code is set high-level settings in VS Code or the various extensions.
Nothing in the Emacs world comes close to the remote extensions for SSH and Docker containers that VS Code nor the Copilot and general AI integration. I can simply install VS Code on any machine, login via GitHub, and have all of my settings, extensions, etc. loaded up. I don't have to mess around with cross-platform issues and Git-syncing my .emacs file. Practically any file format has good extensions, and I can embed Mermaid, Draw.io, Figma, etc. all in my VS Code environment.
Now, I'm sure someone will come in and say "but Emacs does that too!". If so, it's likely a stretch and it won't be as easy in VS Code.
> the only plugins I've installed on Jetbrains's ones
So? No excuse for a poor interactive experience.
It's still kinda slow for me. I've moved everything but WinForms off it now, though.
VS is much faster considering it is a full blown IDE not a text editor, being mostly C++/COM and a couple of .NET extensions alongside the WPF based UI.
Load VSCode with the same amount of plugins, written in JavaScript, to see where performance goes.
Amazon just released OS that uses React Native for all GUI.
Lots of Electron apps are great to use.
Thereby adapted to devs' needs, rather than users'.
I used Visual Studio Code across a number of machines including my extremely underpowered low-spec test laptop. Honestly it’s fine everywhere.
Day to day, I use an Apple Silicon laptop. These are all more than fast enough for a smooth experience in Visual Studio Code.
At this point the only people who think Electron is a problem for Visual Studio Code either don’t actually use it (and therefore don’t know what they’re talking about) or they’re obsessing over things like checking the memory usage of apps and being upset that it could be lower in their imaginary perfect world.
Alternatives have a lot of features to implement to reach parity
Microsoft made a great decision to jump on the trend and just pour money to lap Atom and such in optimization and polish.
Especially when you compare it to Microsoft effort for desktop. They acumulated several more or less component libraries over they years and I still prefer WinForms.
The extent to which electron apps run well depends on how many you're running and how much ram you had to spare.
When I complain about electron it has nothing to do with ideology, it's because I do run out of memory, and then I look at my process lists and see these apps using 10x as much as native equivalents.
And the worst part of wasting memory is that it hasn't changed much in price for quite a while. Current model memory has regularly been available for less than $4/GB since 2012, and as of a couple months ago you could get it for $2.50/GB. So even a 50% boost in use wipes out the savings since then. And sure the newer RAM is a lot faster, but that doesn't help me run multiple programs at the same time.
2x as many chrome instances, no issues
If you didn't have those gigabytes of memory sitting idle, you would notice. Either ugly swapping behaviors or programs just dying.
I use all my memory and can't add more, so electron causes me slowdowns regularly. Not constantly, but regularly, mostly when switching tasks.
Visual Studio Code is a developer tool, so there’s no reason to complain about that.
I run multiple Electron apps at a time even on low spec machines and it’s fine. The amount of hypothetical complaining going on about this topic is getting silly.
You know these apps don’t literally need to have everything resident in RAM all the time, right?
"Multiple" isn't too impressive when you compare that a blank windows install has more than a hundred processes going. Why accept bloat in some when it would break the computer if it was in all of them?
> Visual Studio Code is a developer tool, so there’s no reason to complain about that.
Even then, I don't see why developers should be forced to have better computers just to run things like editors. The point of a beefy computer is to do things like compile.
But most of what I'm stuck with Electron-wise is not developer tools.
> The amount of hypothetical complaining going on about this topic is getting silly.
I am complaining about REAL problems that happen to me often.
> You know these apps don’t literally need to have everything resident in RAM all the time, right?
Don't worry, I'm looking specifically at the working set that does need to stay resident for them to be responsive.
Here's the other unspoken issue: WHAT ELSE DO YOU NEED SO MUCH MEMORY FOR!?
When I use a computer, I am in the minority of users who run intensive stuff like a compiler or ML training run. That's still a minute portion of the total time I spend on my computer. You know what I always have open? A browser and a text editor.
Yes, they could use less memory. But I don't need them to use less memory, I need them to run quickly and smoothly because even a 64GB stick of RAM costs almost nothing compared to how much waiting for your browser sucks.
And price is a pathetic excuse for bad work. RAM gets 50x cheaper and some devs think it's fine to use 50x as much of it making their app work? That's awful. That's why computers are still unresponsive half the time despite miracles of chipmaking.
Devs getting good computers compounds this problem too, when they get it to "fast enough" on their machine and stop touching it.
And memory being cheap is an especially bad justification when a program is used by many people. If you make 50 million people use $4 of RAM, that's a lot. Except half the time the OEM they bought the computer from charges $20 for that much extra RAM. Now the bloat's wasting a billion dollars.
And please remember that a lot of people have 4GB or 8GB and no way to replace it. Their apps move to electron and they can't run them all at once anymore? Awful.
That's ABSURD.
> That's why computers are still unresponsive half the time despite miracles of chipmaking.
Have you ever actually used VSCode? It's pretty snappy even on older hardware.
Of course, software can be written poorly and still fit in a small amount of memory, too :)
> Now the bloat's wasting a billion dollars.
Unless users had some other reason for buying a machine with a lot of RAM, like playing video games or compiling code.
Do you think most users spec their machines with the exact 4GB of RAM that it takes to run a single poorly-written Electron app?
> And please remember that a lot of people have 4GB or 8GB and no way to replace it. Their apps move to electron and they can't run them all at once anymore? Awful.
Dude, it's 2025.
I googled "cheapest smartphones India" and the first result was for the Xiaomi POCO F1. It has 8GB of RAM and costs ₹6,199 - about $62. That's a whole-ass _phone_, not just the RAM.
If you want to buy a single 8GB stick of DDR3? That's about $15 new.
> My motherboard does not support more memory. Closer to hundreds of dollars than $4.
If you are buying HUNDREDS of dollars of RAM, you are building a powerful system which almost certainly is sitting idle most of the time.
> And no I will not justify my memory use to you.
Nobody is forcing you to run an electron app, they're just not catering to this weird fetish for having lots of unused RAM all the time.
What is? The devs or my claim? There are apps that use stupid amounts of memory to do the same thing a windows 98 app could do.
And you can do good or bad within the framework of electron but the baseline starts off fat.
> Unless users had some other reason for buying a machine with a lot of RAM, like playing video games or compiling code.
If they want to do both at the same time, they need the extra. Things like music or chat apps are a constant load.
> Dude, it's 2025.
As recently as 2024 a baseline Mac came with 8GB. Soldered, so you can't buy a stick of anything.
> If you are buying HUNDREDS of dollars of RAM
Not hundreds of dollars of RAM, hundreds of dollars to get a different platform that accepts more RAM.
> Nobody is forcing you to run an electron app
I either don't get to use many programs and services, or I have to deal with these problems that they refuse to solve. So it's reasonable to complain even though I'm not forced.
> weird fetish for having lots of unused RAM
I have no idea why you think I'm asking for unused RAM.
When I run out, I don't mean that my free amount tipped below 10GB, I mean I ran out and things lag pretty badly while swapping, and without swap would have crashed entirely.
IMO The next best cross-platform GUI framework is Qt (FreeCAD, QGIS, etc.)
Qt6 can look quite nice with QSS/QStyle themes, these days, and its native affordances are fairly good.
But it's not close. VSCode is nice-looking, to me.
I've been playing around with different GUI approaches for the desktop, and what impresses me the most about Godot is how lightweight and self-contained it can be while still being cross-platform on both ends.
When did they add that? Last time I used it, it was still based on xterm.js.
Also, technically Chromium/Blink has GPU rendering built in for web pages, so everything could run on GPU.
> GPU acceleration driven by the WebGL renderer is enabled in the terminal by default. This helps the terminal work faster and display at a high FPS by significantly reducing the time the CPU spends rendering each frame
https://code.visualstudio.com/docs/terminal/appearance#_gpu-...
Before that from v1.17 (~October 2017) it was using a 2d canvas context: https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...
My experience with VS Code is that it has no perceptible lag, except maybe 500ms on startup. I don't doubt people experience this, but I think it comes down to which extensions you enable, and many people enable lots of heavy language extensions of questionable quality. I also use Visual Studio for Windows builds on C++ projects, and it is pretty jank by comparison, both in terms of UI design and resource usage.
I just opened up a relatively small project (my blog repo, which has 175 MB of static content) in both editors and here's the cold start memory usage without opening any files:
- Visual Studio Code: 589.4 MB
- Visual Studio 2022: 732.6 MB
update:
I see a lot of love for Jetbrains in this thread, so I also tried the same test in Android Studio: 1.69 GB!
Have you tried Emacs, VIM, Sublime, Notepad++,... Visual Studio and Android Studio are full IDEs, meaning upon launch, they run a whole host of modules and the editor is just a small part of that. IDEs are closer to CAD Software than text editors.
Compared to 20 years ago that's true. But most of the improvement happened in the first few years of that range. With the recent price spikes RAM actually costs more today than 10 years ago. If we ignore spikes and buy when the cycle of memory prices is low, DDR3 in 2012 was not much more than the price DDR5 was sitting at for the last two years.
I had to do the opposite for some projects at work: when you open about 6-8 instances of the IDE (different projects, front end in WebStorm, back end in IntelliJ IDEA, DB in DataGrip sometimes) then it's easy to run out of RAM. Even without DataGrip, you can run into those issues when you need to run a bunch of services to debug some distributed issue.
Had that issue with 32 GB of RAM on work laptop, in part also cause the services themselves took between 512 MB and 2 GB of memory to run (thanks to Java and Spring/Boot).
- notepad.exe: 54.3 MB
- emacs: 15.2 MB
- vim: 5.5MB
I would argue that notepad++ is not really comparable to VSCode, and that VSCode is closer to an IDE, especially given the context of this thread. TUIs are not offering a similar GUI app experience, but vim serves as a nice baseline.
I think that when people dump on electron, they are picturing an alternative implementation like win32 or Qt that offers a similar UI-driven experience. I'm using this benchmark, because its the most common critique I read with respect to electron when these are suggested.
It is obviously possible to beat a browser-wrapper with a native implementation. I'm simply observing that this doesn't actually happen in a typical modern C++ GUI app, where the dependency bloat and memory management is often even worse.
Also, emacs is a GUI app since the 90's .
(I've been aware of Qt for like two decades; back in the early 2000s my employer was evaluating such options as Tk, wxWindows, and ultimately settled on Java, I think with AWT. Qt seems to have a determined survival niche in "embedded systems that aren't android"?)
I think the ship sailed
In order to build a web app, you will first need a web app