Yet another Hacker News

Every Windows 11 app should kill Electron, and Discord just showed why

54 points thunderbong 2 hours ago 55 comments

cheschire 1 hour ago | parent

I'm pretty sure this was known since the early days of Electron. It was even one of the chief complaints about VS Code when it was first launched.

Electron's value prop has always been about having one team producing one app that is supported on multiple platforms with minimal additional effort.

This article does nothing to address that.

RunSet 45 minutes ago | parent

> Electron's value prop

"Now you can have the cross-platform compatibility of a single-page application just by bundling Chrome."

zdragnar 20 minutes ago | parent

It's worth remembering that electron was first released back in 2016 (formerly atom shell fro 2013) so Internet Explorer was still very much a thing.

Not a great justification, but it made a bit more sense then.

tekla 44 minutes ago | parent

The problem is that it made everyone's life worse.

johnh-hn 30 minutes ago | parent

Not mine. I loathe Electron like many people. But, as someone who is legally blind and has very limited vision, being able to have custom UI zoom levels, per application, has made my life much easier.

For a long time, and mostly out of frustration, I wanted to build my own stack of software around my vision. But the mammoth amount of effort it would require meant I never went through with it.

freecodeio 10 minutes ago | parent

nice point, people like to shit on the web but it has one of the biggest accessibility features that most of the gui frameworks would just leave them as feature suggestions for years

hajile 3 minutes ago | parent

I'd note that as stuff like A11y gets added into something like Discord, we'll see the app slowly bloat up to compensate.

Google Chrome generally used around 25mb per tab in 2010. Today, that number is often 500mb or even 1gb.

Grombobulous 16 minutes ago | parent

The electron hate train needs to pull in to the station and be retired. We can just admit that it was a good solution for the problems of its time just like JQuery. Electron was conceived over a decade ago and it was an imperfect solution, but there’s no denying that it was a solution.

Election predates WebAssembly by 5 years and hit the scene only one year after Rust was first created.

And just like JQuery, its time is coming to a close as better frameworks are available now that weren’t available back then.

s3p 14 minutes ago | parent

I never thought election was a good solution for the problems of its time. Just call it a web app and don't lie to people releasing something "native" for them to download.

IshKebab 26 minutes ago | parent

> The article does nothing to address that.

I dunno if you've been living under an enormous rock, but they used AI to make this.

Grombobulous 17 minutes ago | parent

The article at least indirectly addresses that.

At the time Electron came out, there weren’t as many cross-platform UI frameworks available that they could have gone with.

You can see this with the comparison chart. GPUI effectively replaced Electron so the desktop app UI works across platforms. React Native is replaced with WebAssembly so that Rust can be the primary language across all platforms including mobile.

It seems like the new situation for Discord is rather elegant, and that none of this would have been available when it first came out.

accurrent 3 minutes ago | parent

A huge pain of desktop development is managing dependencies particularly if you are coming from C++/Native code. Imagine you want to make simple app that accesses the webcam for instance: If you use chrome you got the full html5 runtime, whereas with other tools you'd need bespoke libraries which your end user may not have.

The only way to ship the same code between linux, macOS, and Windows would have been to either use something like Qt or the JVM back in the 2010s. The JVM desktop stuff was super ugly and Java itself had become notorious (also if you wanted anything remotely interesting like webcam/microphone or multimedia access you'd still have to ship dynamic libraries). Qt required special packaging skills to ship to the end user especially if third party libraries were involved. Electron killed that by bundling chrome (and chrome has a huge api surface).

Today, I would argue the package management situation for a language like rust is a lot different. You dont have to cobble different DLLs together, you can just statically compile dependencies and cargo/rust do a pretty good job of making sure it's bundled with your app.

kryptonomist 1 hour ago | parent

Let’s hope we see a new wave of desktop apps rewritten natively, thanks to LLMs. Whether they use Rust with GPUI, C++ with Dear ImGui, or something else entirely, that would be great. Personally, I’m so fed up with bloated UIs. Windows is full of them, and it’s a pity considering how powerful our CPUs are.

r_lee 1 hour ago | parent

> C++ with Dear ImGui

it would be absolutely awful

compared to chromium, it's really limited, like it's just always a compromise with these

we should instead figure out a way to do electron but better and make it easier to do the things you can do with e.g. React with native languages and frameworks

amelius 1 hour ago | parent

QtQuick is quite good.

debazel 44 minutes ago | parent

The limitations are a large reason for why they're so resource efficient in the first place.

If you just reimplement Electron in a native language then you get... Chrome, which is already written in C++. The majority of RAM usage in Electron applications is from the native parts of Chrome itself and a decent ~40 MiB chunk for the Node.js runtime.

caspper69 38 minutes ago | parent

I have had excellent results running a back-end Rust process that communicates with a C# Avalonia front-end via protobufs over named pipes on Windows and Domain Sockets on Linux and MacOS. With C# AOT I’ve been able to create self-contained apps that run incredibly fast despite the ipc between the front end and the rust core. I’m getting full 6 platform coverage too (Win/Linux/macOS on both x64 and arm64).

edit: Avalonia is quite mature, with accessibility to boot.

the__alchemist 6 minutes ago | parent

Are you a web dev?

airstrike 1 hour ago | parent

or Rust with things other than GPUI

cpursley 48 minutes ago | parent

Crux, lets you use native UI but Rust for business layer: https://github.com/redbadger/crux

itopaloglu83 1 hour ago | parent

On another note, Microsoft Teams and new Outlook use very little amount of memory on paper, because their main windows show up under the Edge name. It’s a Microsoft way of solving the high ram usage problem.

goda90 1 hour ago | parent

WebView2. Other applications can also use it but it seems like there's less out-of-the-box functionality than Electron

jasonvorhe 1 hour ago | parent

By being dishonest and misleading?

pwg 43 minutes ago | parent

When has Microsoft not been dishonest and misleading? Being dishonest and misleading has been Microsoft's entire game plan since all the way back into the Bill Gates era.

lunar_rover 2 minutes ago | parent

By reusing the system webview? It's what web frameworks should've done.

senorrib 1 hour ago | parent

That’s also how Tauri claims to use so little ram.

petterroea 1 hour ago | parent

It's hard to say "Discord just showed why" before the product is in production and sees actual use. Promising initial statistics, but the transition is based on a lot of assumptions that won't really be proven until mass adoption and the software has seen long-term maintenance.

flohofwoe 52 minutes ago | parent

...exactly, and at some point you want to show inline animations or videos and all sorts of other media, show webpage previews, play audio snippets and all the other things things a webpage can do, and then you're back to either integrating a browser engine or attempt to write one from scratch (the browser engine can of course be provided by the system webview, e.g. what Tauri does).

goalieca 38 minutes ago | parent

I’ve programmed inline video players for 25 years. Same with audio and everything else. We had “accelerated” graphics back with winxp and gdi+ and of course OpenGL over ssh with x11. Browser preview pages in most apps are usually snippets of text and maybe an icon or pic. Not rendering a full page.

In a way, applications regressed a lot with react native and electron. I get it’s easier to develop but the apps are very bloated and underperforming even on computers with 10-100x more power.

Neywiny 1 hour ago | parent

They keep talking about 2 accounts logged in so that's why it's still high. But they've done nothing to defend that claim.

Also, pro tip, you can still just use it in browser. I hope that doesn't go away.

LoganDark 1 hour ago | parent

I would not add alternative accounts to the account switcher, they've used these to coordinate bans ever since the account switcher's inception.

opengrass 1 hour ago | parent

Signal is still dragging Electron, can't have a working FreeBSD port due to dependency hell. Also VSCode.

fg137 53 minutes ago | parent

Meanwhile Zed isn't really usable on machines without a GPU e.g. VDIs

https://github.com/zed-industries/zed/discussions/17212

I don't know if we have a winner here.

smusamashah 1 hour ago | parent

We have gotten so used to slow app startup these days I believe. I have recently started using Task Slinger [1] and every single time I boot it, I get a feeling that it was already running and it's window just showed up. I wish all modern software were like this.

[1]: https://taskslinger.net/

swinglock 41 minutes ago | parent

All modern apps are like this. It's Electron apps which are all legacy.

LaurensBER 1 hour ago | parent

Electron is pretty awesome in that it allows a small team to build a decent GUI app using their existing web skillset but it also feels like it's time for something better at this point.

With the ram prices as crazy as they are. It's pretty frustrating to have to run multiple GB eating applications just to do some basic tasks (90% is read and write messages, in the case of Discord). I understand that other people might use the more advanced features (voice chat, etc) but these could be loaded on-demand.

It's a bit crazy to me that I can comfortable run an entire Linux stack (+ Podman, monitoring, alerting and multiple services) in 512 MB ram (with 40% free, just checked!). However my Windows PC needs 5.5GB just to show the desktop! Realistically it needs somewhere between 8GB and 16GB for some basic web browsing and even then it can feel slow if you have a few apps like Discord running in the background.

pasc1878 44 minutes ago | parent

Sorry can you show a decent GUI app in Electron compared with a native one.

You show this by all your other comments on memory. The reason apps take memory is Electron.

Plus I prefer apps that behave like OS native apps not the reduced GUI of web apps.

bemtevi 1 hour ago | parent

I've rarely liked any Electron apps, both for the performance and because it seems to encourage a feeling of bloatedness, for want of a better word. Tried VS Code, but dropped it when they started putting too much AI in it and too much complexity. Sublime is so much better.

I don't know...there seems to be something unpleasant about all Electron apps.

cpursley 49 minutes ago | parent

Great option for this that lets you use Rust along with real native UI for cross platform: https://github.com/redbadger/crux

bscphil 13 minutes ago | parent

"cross platform" I just spent 10 minutes trying to figure out what it uses for native on Linux, and whether it supports both Qt and GTK. Turns out the docs don't even mention Windows? "Cross platform" is now just MacOS + iOS + Android + Web? I guess the thought is supposed to be that crux helps you port your app to Windows if you want to... but even the example applications only run on those four platforms.

Doohickey-d 23 minutes ago | parent

One nice thing about Électron is that it supports accessbility and non-english IMEs correctly, and thus all Electron apps have decent accessibility out of the box, comparable to web apps.

Most Rust GUI toolkits, at least in 2025, did not have that good accessibility or IME: https://www.boringcactus.com/2025/04/13/2025-survey-of-rust-...

Hopefully this has gotten better and the new discord client isn't worse in that regard.

robin_reala 4 minutes ago | parent

GPUI has a single-paragraph accessibility section in their guide that defers to AccessKit[1] for everything, and points to a raw RS file for more info.[2]

I haven’t tested it or written anything using GPUI, but I’d expect it to be considerably harder work, based on the maturity of the web stack in this area. My assumptions have definitely been proven wrong before though… Anyone from Discord working on accessibility want to chime in?

[1] https://accesskit.dev/

[2] https://github.com/zed-industries/zed/blob/main/crates/gpui/...

tapper 23 minutes ago | parent

I hope they can do some work on a11y because it's bed. Not as bad as it was but still slow and clunky to use with a screen reader.

tapper 16 minutes ago | parent

Could they of used servo?

mococa 15 minutes ago | parent

On my mac I’ve banned Electron apps, only native ones - Slack on Safari.

azuanrb 13 minutes ago | parent

Electron has always been about shipping cross-platform apps quickly, at the cost of higher memory usage and potentially worse performance. With or without LLMs, its core value proposition remains the same. LLMs simply amplify the framework’s existing strengths.

Raycast, originally a native macOS launcher, recently released v2 using a hybrid architecture. It’s not Electron, but it follows a similar approach to Spotify’s desktop app, using web technologies inside a native shell.

The memory usage is still pretty significant. It’s using around 350–450 MB at idle and can sometimes reach 1–2 GB depending on the workload. The upside is that they can now share most of their code across macOS and Windows and evolve beyond being just an app launcher.

It’s always been about trade-offs, and LLMs don’t fundamentally change that.

scosman 7 minutes ago | parent

LLMs do change the tradeoff if you can now ship cross platform apps quickly, without electron.

GPUI is one example: some of the downsides of electron (UI is not native), but it solves memory and performance side, and shared codebase.

Just writing native apps because LLMs makes it cheaper is the other option. Shopify did this after years of react native.

JustinELRoberts 11 minutes ago | parent

The barrier to entry for GPUI might be a bit high for some, but is there really any argument to be made against migrating to Tauri?

the__alchemist 7 minutes ago | parent

Tauri's value prop over EGUI and GPUI is that its syntax is familiar to web devs.

jrmg 8 minutes ago | parent

I don’t doubt that this will be faster and smaller than the current app, but it’s slightly annoying to me that the new app is getting so much coverage with specific claims about speed and memory usage when it’s not actually feature-complete or released yet.