This bit is obviously subjective, but Rust as a language is simply not ergonomic enough for a lot of the use cases people are trying to apply it to, especially UI development. Most of the Rust UI libraries I've seen to date either use a more imperative style, or attempt to replicate more declarative approaches like Compose UI or SwiftUI, but without the nice language aesthetics that make it simple to read and write. And if the counter-argument there is for LLMs to be reading and writing this stuff, that's a whole other can of worms: (1) The subsidized inference era is quickly coming to an end and (2) if you're using LLMs anyway, why not maintain apps that are as native to each platform as possible?
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.
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.
It's also had a ton of work done to make it performant. (Microsoft level resources)
I think people become super lazy... "Ah, it's will ocupie a few hundreds of RAM, no problem, let's ship it."
They are companies with billions or even trillions shipping shit with Electron.
I’ve worked in Qt apps on and off through my career.
I do not want Qt apps any more than I want Electron apps.
The solution is native apps using native platform tools, or one of the mature cross-platform toolkits.
I too had code that worked across 3 platforms with wxwidgets and a 3D game toolkit incorporated in opengl for visualisation, with most 2d controls being drawn using wxwidgets OnPaint handlers for custom controls rendered natively on that platform. I wrote this single-handedly, with another colleague handling the network code and firmware on the remote hardware devices.
Everything else is sheer laziness as far as I am concerned. There's even less excuse today with the rise of LLMs to do the majority of UI coding for you.
What seems to have changed is the size of the costs - LLMs are really good at this - such that you can now say “well, maybe the returns aren’t that big, in fact maybe they’re zero, but this is easy enough, so why not”
De minimus improvement has always suffered this problem - we’re all fairly sure it’s worth something. Maybe there’s even real perceptible value when you fix the whole basket. But making the case is hard.
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.
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?
[2] https://github.com/zed-industries/zed/blob/main/crates/gpui/...
I don't know...there seems to be something unpleasant about all Electron apps.
I did use VS code for a while but I've just gone back to using QT Creator simply because it is so much faster to use in daily life.
Hiwever, I'd like to hijack this front page article to for a related concern/question I've got.
It seems that all (popular) opensource LLM harnesses are either in JS or python (pi, hermes, opencode, paseo). The same seems to be true for closed source harnesses that I have used (deepseek, chatgpt).
I'd really like to ask why? I mean why somebody would use technologies like JS or python to implement a harness application instead of golang or rust or even C? I understand that before 1 year JS or python would be tempting but right now? Especially the LLm related companies have unlimited tokens and re-writing the harness software to golang or rust should be trivial.
This would benefit so many people (especiall considering the prices and scarcity of RAM these days).
So, why nobody does it? This is an honest question, I don't want to offend interpreted languages but it should be a universal truth that a compiled language is faster and consumes less ram.
The resource usage of my harness is nothing compared to an electron app, and being able to easily customize it is more important to me than saving a few extra MB of ram.
These are not the same units, because all modern OSes have compressed swap.
Myself? I care. I regularly run a project that needs 6GB for the language server to provide type hints.
Ask anyone with a 5 year or older laptop that wasn't top of the line when it came out and can't afford a new one, and I think you'll find they're of the exact opposite opinion. And even if they aren't explicitly, they might have abandoned their PC and instead switched to their phone for their personal computing, just because that experience turned out more coherently for them.
Heck, even the normal user with a decent laptop probably would take better performance if given the option, but when have they ever been given that option? The current state just isn't unperformant enough that it crosses the threshold to the point where it's at the front of mind for people. If anything, that threshold is probably beyond the threshold of 'eh, I'll just use my phone for this' for any task that doesn't need a keyboard.
Anyone who ran Windows 2k , or OS 9 remembers when apps opened instantly and were always responsive, because IO was dog slow (both disk & network access) -- no one dared to block the UI on an IO call.
Give us back our hardware!
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.
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.
The opposite is also true. My argument is that you can also ship Electron apps with more features more quickly with LLMs.
You still have a finite token budget. With native apps, you have to split those tokens across multiple platforms, whereas with Electron, you can reuse most of the code.
Big companies have been going back and forth between native and cross-platform approaches even before LLMs. They generally have the resources (humans, tokens, compute) that small and medium-sized companies don’t have. So I’d take their rationale with a grain of salt.
Also, pro tip, you can still just use it in browser. I hope that doesn't go away.
Discord is a server-side protocol (the client isn't doing much besides displaying the server-prescribed state), there's very little logic/computation going on on there that should explain a world of difference.
Nowadays, AI (LLMs, genAI, call it what you will) has become so cheap to handle more than one codebase, they no longer feel the need for web only approaches.
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
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.
Regarding "not doing what you can do with HTML/CSS/JS". Doubt. I varied and complex stuff and have never felt I needed to overload document rendering langs for this.
I will go a step further: I don't think Electron is a symptom of HTML/CSS/JS: I suspect it's more from the Node + Framework culture.
you simply just would stumble if you tried to do development like you can in React, constant "uhh... can't do that." while it just works in React.
I don't think anyone likes the look of Qt more than what you can achieve with webapps in terms of UI (style/etc. wise)
problem is the performance, I don't think many would be complaining if the performance was proper and the memory usage wasn't as terrible as it is now
you're talking about web browsers, I don't care what it runs on, if we have a way to run this in a lightweight way, would your complaints go away?
even Gnome uses JS etc.
you can do complex stuff in native UI, of course you can
what I'm talking about is the same kind of DX as with React. I really don't have faith in that, e.g. the new thing Discord is about to use, the css it tries to imitate just seems absolutely terrible.
the web technologies aren't perfect, in fact, far from it. however, when I see React vs whatever C/C++ alternative, I'd always go for React if it's about making the UI nice.
I've also shat on Electron before, but there's a reason as to why it's so popular. the tooling/UI capabilities are just much more powerful.
I don't want web app UIs. They all look different for no good reason. I want native UIs. I like qt. Please just give me a stable UI that I learn and stick with for the next 20 years.
You are incorrect. In fact, us users hate that fact that UI designers keep making apps that look nothing like the rest of our system. Give me a nice native-looking app any day of the week.
edit: Avalonia is quite mature, with accessibility to boot.
I'm well aware that Electron has a large RAM footprint and installation size, but doing a polyglot architecture instead puts more cognitive load on you. Projects that mix multiple languages are a pain just to manage. I'd rather hope Electron gets better optimized.
Everyone always blames the browser. Why don't we blame [insert native app framework] for apps being slow too?
Everyone builds web apps using bloated frameworks and don't spend time optimizing any of their code. I wonder how much more efficient they could've made the Discord client without getting rid of Electron, just for a more meaningful comparison.
Discord is probably my least favorite thing to happen to chatting online, but for some reason it's what everyone wants to fucking use.
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.
At least now Discord will consume your GPU vram while you game.
I am guessing this is just capture/playback code issue? You have a portable WebRTC stack in rust https://github.com/webrtc-rs/webrtc
I haven't used Tauri myself but this sounds like a fun thing to go fix. Silly this is a blocking issue.
https://github.com/zed-industries/zed/discussions/17212
I don't know if we have a winner here.
Also, browsers contain too much bloat, why do you need support for elements like "hr" or attributes like "cellpadding" in a modern app? Throw away all legacy garbage.
Also, immediate mode UIs (like Rust's egui) are even worse garbage than a browser. "Immediate mode" means that on every mouse move a function is run that re-draws whole window from scratch. I tried running PhotoCraft (uses egui) in a VM with no GPU and it felt like playing a game at 3 fps. The CPU is simply unable to redraw whole GUI with acceptable speed. It will be especially bad on 4K and 8K screens.
Electron apps are a disease.
BUT BUT THEY LOOK GREAT, LOOKING GREAT SHOULD COST 1000$ OF RAM BUGA BUGA...
Yeah, it takes some extra ram. Fork my stuff and rewrite it in rust if you care. I don't. The few hot spots can be fixed by using a lower level language. Is vs code not zippy enough? I certainly haven't noticed the slowness. People keep complaining about unnecessary load as if hardware hasn't progressed since 2004. It's hugely important for things like your OS. A few apps you run twice a month? Who cares.
But what about software used by billions, asks a person angry about my electron project used by thousands? How many ages were taken up by the five second startup time when you multiply that by however many users (all this time would be spent curing cancer of course)? Sure, improve performance when needed. For the vast majority of projects it's not needed. The average computer isn't pi zero.
And that, right there, is why people hate apps which use Electron. You are spending my system resources so that you can be lazy and not have to program as much. That's not really acceptable development practice.
Not to mention Windows is a very heavy slow inefficient and poorly made OS.
You don't see these issues generally on Linux or macOS.
Slapping a few million lines of AI generated slop code ought to do it for instance.
Discord’s new Rust client had its friends list loaded before the current Electron app could get past its loading screen, in a 15-second clip that we found on the X account of Discord co-founder and CTO Stanislav Vishnevskiy. The video had 2.3 million views at the time of writing, and Discord employees have confirmed that both apps were launched from a cold start.
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.
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. Other languages also now have similarly useful tools.
Chrome had already solved the hard problem of "how do we support webcams on linux, windows, and mac" and you as the dev just needed to use the Javascript webcam api. ( https://developer.mozilla.org/en-US/docs/Web/API/MediaDevice... )
In C++ land, you are ultimately going to either need to cook up your own webcam library or look for a 3rd party (which, in 2010, likely didn't exist) to provide it.
Today, there are a few easy to discover rust crates which provide cross platform webcam apis. But further, rust does cross platform better than C/C++ IMO. It's really easy to change how code is compiled based on the target. That was all well thought out because rust was supposed to be a language for browsers.
However that has been true since 2016, and here we are, 10 years later.
The real difference is that Rust provides a package repository with a unified build system that's as simple to use as NPM or NuGet.
vcpkg which is similar exists today, but it didn't in 2015 when Discord started, still isn't anywhere near as comprehensive as package repositories for languages where package management is part of the standard toolchain, and the underlying build systems are far messier under the hood.
It can also be helpful in development to use libraries built from source as part of the application's build process, at least as an easily-accessible option, which wasn't common practice in most C/C++ ecosystems historically where different libraries used different build systems and if you wanted to integrate them into something like a Visual Studio solution for easy reference to source code during development and debugging you were often on your own.
Strangely enough we managed to write portable code across platforms during the last century, and there were more than only three major desktop OSes.
Yep, that argument always seems strange too me. Do people fear that much to design their own interface and hook to each platform ecosystem? You look at something like the BSD which runs brought one single kernel concept and various subsystems across a variety of hardware. And somethine like libao[0], which provides a common interface to various sound system.
Whatever the app, if you care enough, you can abstract the core features away from the GUI and other various dependencies.
[0]: https://xiph.org/ao/
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.
> Hi Stanislav, I'm one of the core maintainers for GPUI at Zed, if anyone at discord would like to talk to us about improvements to the framework or to upstream your customizations, please get in touch! My DMs should be open :)
https://twitter.com/radgendervibes/status/211810701651020193...
The first thing anyone would want to know when choosing a GUI framework is how it looks by default. Every major GUI toolkit has screenshots on their websites.
This happens so often it makes me wonder if people just don't know how to take a screenshot and put it in a webpage with <img>.
This has been addressed many times now, and the article doesn't really need to re-address it.
Coding LLMs make managing cross-platform native apps significantly easier than it was in the past. The cost-reward analysis, where Electron and simile apps made sense because then you don't need to have an iOS expert, a macOS expert, etc, and having a bloated monstrosity of an app is an acceptable compromise, is simply no longer true.
I know there is some subset of HN that still thinks CoPilot 2024 is the state of the art and will declare this a foolish assertion that good developers like them disbelieve, but this is what all of the industry is moving to.
"Now you can have the cross-platform compatibility of a single-page application just by bundling Chrome."
Not a great justification, but it made a bit more sense then.
The solution is to use user interface toolkits that are available on each platform. For example, wxWidgets or Qt or appropriate bindings to them if you can't be bothered to write UI code for each platform you're targeting.
Why not? Microsoft released IE for win16, win32, wince, macos system 7 through 9, macos X, Solaris, HP-UX. If it ran on all those platforms, Microsoft probably could have supported it on any platform that had the capability of running graphical web browsers.
I dunno if you've been living under an enormous rock, but they used AI to make this.
That can be done. It can be done well. It's not (or rather never has been) cheap or flexible or agile (in the market, not SWE sense). People love HTML/CSS/JS for very good reasons, and have been willing to accept the resulting tradeoffs.
Maybe that's changing now that you can vibe-port a lot of this stuff. We'll see.
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.
Google Chrome generally used around 25mb per tab in 2010. Today, that number is often 500mb or even 1gb.
What's oddly being ignored in this entire thread (so far, as of the time of writing) is that back in 2017-2018 Discord was an Electron app and was completely inaccessible. The web did not magically bring accessibility to the table -- we disabled people had to go yell at Discord to fix their shit, and even then it took them like 2-3 years, and even now Discord has some very very weird accessibility issues that will randomly crop up here and there.
And it doesn't require that huge amount of RAM, no. What requires the Chrome RAM is running JavaScript and do it fast, and a lot of extremely complicated features, most of which a single app will never use.
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.
We would be lying if we did that. Electron was never, ever a good solution. It was something solely used by devs who prioritized their own ease of work over the actual user experience, i.e. bad devs.
Acting like this is a decision the ICs make is disconnected from why electron is so prevalent.
Someone would have been able to disrupt that market by making a much better chat app since Elecron is so bad for user experience.
Why do you think that is?
I'll give you a hint: if I close my web browser, how do I get a notification that I got a new message? Make sure you also pretend it's 2015 (launch year of Discord) and that I might be using Firefox, Safari, or Edge.
The funny part about this complaint is that you can literally just use the web app if you hate the desktop Electron app so much. That's one of the main benefits of Electron!
Discord isn't packaged as an Electron app simply because it pretends to be native, but because it has an entire system integration layer that isn't available in the web version.
Luckily in the modern era we have invented language models, which allow us to expend vast resources on text generation instead.