[aerhardt]

I’ll reply to your question with a question: once VSCode has proved one could build hyperscale complex apps that perform well, would you be fast to bet for less proven tech?

I’ve had a great experience using VSCode on occasion (I’m a JetBrains guy), and loads of other people, including some great programmers, rave about it. I’ve similarly had a fairly solid experience with Spotify desktop across different platforms.

I’m asking genuinely, is it such a subpar choice when there’s such proven success cases?

[matt_holden]

Also: Figma, Linear, Notion, Slack, Superhuman, Pitch, Loom. All Electron.

I’ve never understood the hate Electron gets on HN, when it powers so many great products that users love.

[bboygravity]

I don't think you realize how slow those are, how slow they make your entire machine (eating the RAM for no good reason) and how insanely fast similar apps could be if written in something that doesn't involve massive bloat.

Electron is also how Microsoft essentially broke Skype (on purpose?) IMO.

For me Electron just stands for lazy companies/devs who are not interested in producing something elegant that runs as fast as possible.

[esperent]

> I don't think you realize how slow those are, how slow they make your entire machine (eating the RAM for no good reason)

You're on a forum full of software developers, I think you can give us credit for knowing exactly how much resources the apps we use take up.

Personally, I frequently run VSCode, Slack, Zoom, Chrome, and occasionally Loom at the same time on a machine with 8gb ram and it's fine. Until one of these new platforms like Tauri or Socket.sh catches up, the trade off for developers being able to develop once and run on multiple platforms is entirely understandable and clearly acceptable to most people.

[qorrect]

Fully agree on all points, I've never had a performance issue with Electron.

I have had Slack fill my home directory with logs once , long time ago. But that wasn't an electron problem.

[Kiro]

Cool. I'm a single developer releasing software for free which is only made possible by Electron and wouldn't exist without it but I guess I'm just lazy.

[qorrect]

You're lazy and you should feel bad! /s

[eecc]

Honest question: where does all the RAM go? If a chrome tab eats about 200 MB ram, shouldn’t an electron app consume about the same? After all Electron is just an SPA with all the assets packaged with the browser engine. Like the zip’d web archives of yore

[0x073]

Chrome engine is build for browsing the web multiple windows multiple tabs etc.

If you drive with a empty truck with trailer it uses more oil than a car.

Chrome is not designed for this. There are other engines like https://sciter.com that are work for single apps, but probably scale bad if they are misused as a browser.

[lozenge]

I just opened Chrome to a news website and got 400MB of usage on the "GPU Process", 150MB on the "tab" process, and 100MB on the "browser" process. In Electron the webpage doesn't have access to native APIs like the system tray, so that's done by exchanging messages with an extra process.

[TexanFeller]

The ones of these I've actually used like Slack are doggie doo. Aside from using way more resources than a chat app should, last I checked basic UX was not close to on par with native, like right mouse clicks didn't do anything but bring up the built in browser menus.

[operatingthetan]

>like right mouse clicks didn't do anything but bring up the built in browser menus.

You should try this in slack again...

[chrisweekly]

That UX decision has nothing to do w/ Electron.

[operatingthetan]

If someone brings up a single example they should ensure it aligns to their criticisms, as a rule.

[clumsysmurf]

I don't mind using an Electron app. The problem is, they are multiplying too fast. I currently use: 1Password, VS Code, Discord and / or Element, Obsidian, and Postman. They use most of the machine's resources doing nothing at all.

[shp0ngle]

Slack took great pains to make the client not be a memory and CPU hog.

Still better than Teams though. (Which is also in Electron.)

[pantulis]

You can also see the pains the Evernote team took from the initial Electron-based 10 release until it became usable again. But you could also feel the product moving again after stagnation on a gazillion native clients. It was the right albeit mostly final engineering decision they took.

[pqs]

It surely was the right decision, but it came too late.

Also, still the app is almost worthless on my Android phone. Too slow, despite large improvement.

[detrites]

"Powers" being a relevant word here. People love to call out various tech/choices for needlessly sending our energy into a black hole, has anyone run the numbers for Electron's negative impact versus a non-wasteful solution?

[2h]

> VSCode has proved one could build hyperscale complex apps that perform well

did it though? It might perform "good enough", but its still an order of magnitude worse than native solutions. the only reason to ever use Electron or similar is for rapid prototyping. once you have an MVP, you should immediately work towards a native solution. people seem to forget that part, out of laziness or ignorance.

[jeremy_wiebe]

I use VS Code daily and I have never had performance issues. That obviously doesn’t apply to all folks.

Also, it seems presumptuous to prescribe what appropriate solutions are for all people of all time. There are many, many places where an electronjs would be just fine.

[yjftsjthsd-h]

> Also, it seems presumptuous to prescribe what appropriate solutions are for all people of all time. There are many, many places where an electronjs would be just fine.

And many where it wouldn't. It seems more presumptuous to me to demand that users have machines with that much memory and CPU to spare.

[zztop44]

No one is demanding anything. VS Code exists. Lots of other code editors also exist. Many are native. Choose whichever one you want.

[Ygg2]

I did use it and find it subpar to JVM based IDE (namely Jetbrains). Yes, both are memory hogs, but Jetbrains feels smoother.

[Renaud]

You have to define ‘worse’ because raw performance isn’t really everything and vscode’s popularity proves it.

Feature set and extensibility have clearly won here. At a certain performance point, it’s good enough and what you can do with it matters more.

I’m not sure you could achieve the sane flexibility in a more native, “bare-metal”, development environment. Possible, yes, but it would probably not be as successful as developing for it would be somewhat harder.

Vscode is “fast” enough. Its extensibility and its ecosystem are what makes it so popular and successful.

I’m not sure you can build the same without trade offs.

[eastbound]

> once you have an MVP, you should immediately work towards a native solution.

All of the chat apps that worked towards a native solution have died. Most of the other apps too, but all of the chat apps. Going native, despite being satisfying for the user, carries a maximum cost in terms of internal organization (several departments in the company for each target OS), HR (developers that can’t be recycled in other departments), marketing: “Wait, does HipChat MacOS has the same features as HipChat-on-the-mac-but-in-browser? Wait it doesn’t matter, HipChat is dead.”

[gbear605]

Telegram, which is easily the best chat app by software quality, has native apps on all platforms (well, QT on desktop, but that’s close enough). iMessage is native as well, and widely used, though it has admittedly fewer target devices. Those are the two I use daily, so I definitely don’t live in your Electron world, and I’m happy for it.

[simonw]

What's your theory on why the VS Code team haven't migrated to native solutions for their app?

[AlotOfReading]

They do have a native solution you might be familiar with, "Visual Studio". It took them a solid decade to port it even from 32->64 bit (finally released last year). Hard to blame them for some institutional PTSD around the whole idea of native apps.

[madeofpalk]

What are the 'native solutions'?