That's like saying it would make sense to make Internet Explorer work on all platforms. It doesn't make sense.
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.
> That's like saying it would make sense to make Internet Explorer work on all platforms. It doesn't make sense.
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.
Maybe because wxWidgets is garbage DX and UX wise, and Qt isn’t free and doesn’t allow you to reuse web code? One of the value prop of electron is to reuse your web codebase.
How is wxwidgets garbage DX and UX wise? You can literally read the source code and can build the library in 5 minutes, and the UX is native user interface elements of the given platform.
I don't see how reusing web code is an advantage. Web code is for the web. We are talking about a native platform (Windows 11) which has a mature API platform stretching back decades. Why would you need to make it "web"?
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.
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
i switched a cross platform application TO web stack for this reason. accessibility and screen reader usability is incredibly important and massively overlooked in many domains
The Windows settings scale resources for the OS, not per application. The more applications you use, the worse these settings become. If I'm unable to use an application's own features to modify the size of something in its UI, I have to fall back to the Windows settings. That leads to the following:
1. Use the make everything bigger/font size settings to change the size of what I currently can't see
2. Restart
3. Open every application I need, and go through every major feature in each of them to determine if I can still see things comfortably, while making sure no elements have exploded in size as this also leads to usability problems
4. If not, go to 1
I have to do this every time I install a new application, or one of them updates and changes their UI or decides to opt into the Windows accessibility settings. The latter one happened a few years ago with Firefox, and cost me a day to sort.
Invariably, it leads me to compromising on what I can and can't see.
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.
> We can just admit that it was a good solution for the problems of its time just like JQuery.
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.
Its a straight-up business decision, generally made by MBAs and with advice from engineers and executed by the engineers. That's because it changes the shape of the org when you need a separate team for each platform, so any org where the benefit of doing so doesn't get articulated sufficiently, will end up with fewer devs covering more platforms.
Acting like this is a decision the ICs make is disconnected from why electron is so prevalent.
If it’s so easy to provide a better user experience using something else besides Electron then logically you should be able to point to chat apps that won over more user adoption than Slack and Discord.
Someone would have been able to disrupt that market by making a much better chat app since Elecron is so bad for user experience.
I made a bunch of Electron apps in my time. I always tried to talk the client out of it. "Just make it a website" I would say. Still, there were times where it made sense.
Electron was an ok solution to the problem they were looking at, “how do I waste as much compute as possible.” Unfortunately it had the side effect of drawing a bunch of stuff on the screen.
Luckily in the modern era we have invented language models, which allow us to expend vast resources on text generation instead.
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.
Why https://gpui.rs/ doesn't have a single screenshot of how it actually looks?
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>.
GPUI works well for Zed, but it's built for Zed's needs only. There is no official crates.io udates. Breaking changes land as Zed needs them, and outside PRs often get declined causing a mess of several forks.
Herdr's new native app uses GPUI for it's mod framework, so hopefully as more apps adopt it, a better community/package/release process builds around it.
GPUI/Zed devs are trying to contact discord to see what can be improved:
> 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 :)
Honestly GPUI feels like the closest thing we have to a working UI framework for Rust. That's probably because GPUI is not developed in a vacuum, it actually needs to work at Zed's scale because they ship a real product and GPUI needs to deliver.
I'm very excited to see GPUI extended for general purpose usages in the future.
A huge pain of desktop development is managing dependencies particularly if you are coming from C++/Native code. Imagine you wanted to make a simple app in the 2010s 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. Other languages also now have similarly useful tools.
But then the C++ libraries you mentioned also had the ability to statically link into a binary, which means you could statically link the webcam access in, in your example. So I don't see the advantage you're arguing for?
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.
Neither existed in 2012, so of course not. On the other hand, QT has always been really easy to download from QT. I don't remember who owned QT in 2012. They've changed hands a couple times over the years, but in 2012 I was downloading QT from whoever on them. QT was large, so you needed a decent sized computer to build it, but in 2012 this was not a big deal.
People get too hung up on package managers. When you're building your own proprietary you don't really need a package manager, you just need a central place to download the tarballs from. Or you could do a monorepo and just build everything locally - in 2012, that means you start your build before you leave Friday afternoon, and when you come back Monday, everything's built.
A cross platform webcam library isn't that hard to build at C++. I mean, it's tedious, and having to support multiple different operating systems makes it harder, so it certainly is going to cost a small pile of money, but this is not hard. The pile of money needed won't be all that large. Mind you, I prefer to use something that's off the shelf rather than writing my own, but it would not be hard to write my own.
The hard part of all webcam libraries is all the different webcams running all their different proprietary protocols.
Write the code or build the code? That's always the problem with C++ libraries.
It's not that difficult to write cross platform C++ code. Consuming the dependency is always painful. What build system does it use? What compilers does it support? How do you get the code? There is 0 standardization for these things.
C++ code isn't always that portable either. Old code in a new compiler is very likely to break on warnings, especially if the old code made the high quality decision to hard code -Werror in their build system.
From personal experience Rust as a package and ecosystem is far more portable than C++.
It is 2026 and regardless it has been quite a while that cmake fetch content had been usable.
The only reason why a cross platform well supported C++ package/module isn't available is because nobody has bothered to build it.
If it really is something that bugs you then be the one to do it, throw your clanker of choice at it and integrate it into a project you run in production.
"Chromium ahips with it" isn't a valid excuse these days, that is likely an hour or two away with a modern LLM, building and packaging electron is more work.
Dynamic vs static linking is mostly a red herring for desktop GUI application development unless you want to integrate into something like Linux distro package managers, as dynamic libraries on Mac and Windows can be self-contained within the application bundle/directory with no disadvantage beyond marginally longer startup time, and you can do similar things with Flatpak and friends on Linux.
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.
Java desktop was only ugly if you chose for it to be. It was pretty minimal effort to get native look and feel. Nothing built in electron looks native. If we're accepting custom interface using electron, that was doable with Java too.
JetBrains IDEs arguably look/behave better than VSCode as far as a native app goes. I wouldn't say either look great on MacOS but a truly "native feeling" Mac app is usually quite different than a Linux/Windows equivalent.
Long time ago, Apple had a proper OS X Swing L&F, when you could do Cocoa in Java, and there was still some uncertainty if Objective-C would be embraced by Mac OS development community.
A Swing application looks ugly and not native by default, but the platform allows to plug a different look'n'feel. With small effort, you can make it look nice with something like flatlaf [1]. Pretty sure there are others, I haven't done Swing UI in a while.
They had native looking skins for Swing that still felt slightly off and behaved differently. Netbeans IDE looked nice, but it was weird in subtle ways.
> Strangely enough we managed to write portable code across platforms during the last century,
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.
I never really understand this attitude. It isn't really hard it took one or two evenings to understand how native libraries work and you close this problem forever.
>Qt required special packaging skills to ship to the end user especially if third party libraries were involved
How outrageous to demand that a software developer possesses the 'special skills' to ship a Qt application. It's not surprising that people think AI is killing programmers when this is the level the average 'programmer' has been operating at for 15+ years.
Imagine going to a chef and he tells you he can only warm up microwave lasagna because cooking the steak correctly requires special skills. The special skills are your job
Exactly. This Discord Windows 11 rust app doesn't run on Mint or AOSP or an iPad and won't without extensive porting.
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.
Using Rust/wasm for a mobile apps sounds crazier to me than using Electron on desktop. I'm not sure of the details there but the APIs/SDKs bringing consistency is one of the best parts of mobile. There's less of an argument for that on desktop which moves slower and is mouse/keyboard instead of complex set of touch workflows, paging, and notification schemes.
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.
The article explains that the same Rust app runs on Windows, Linux and Mac just like the Zed editor where the GUI library originated, and with wasm, also runs on iOS and Android. What else do you need?
I'm not sure if a cross-platform UI framework is a good idea or not. I've been building with QT for 15 or 20 years now, and I'm still not sure if cross-platform framework is a better idea than just writing a different UI as a thin layer on top of your business logic for each platform.
Certainly, if you write a native UI for every platform, you're going to need a few more people because you have to have someone who understands each platform. However, with a little bit of work you can define some good interfaces to that UI and most of your needs are going to be things that are not the UI framework but they're logic that can be cross-platform.
What cross-platform frameworks give you more than the UI is all the other pieces you need. I've written a bunch of applications in Qt Core with no UI at all because it's so convenient to have those Qt abstractions.
>It was even one of the chief complaints about VS Code when it was first launched.
That was absolutely not the case at all. At least not on HN or twitter. It was for Chief Complaints for Atom. When VS Code first launched everyone was suggesting how much faster it was compared to Atom. And how a properly tuned Electron Apps could be fast. And Microsoft promised it will get even faster that makes everyone excited.
The only few of us who were complaining was how could everyone judge this to be fast when we have Sublime. And that was even before Sublime had GPU rendering.
I think OP is both right, and there was people still complaining about it. Atom was seriously slow. Everyone said you couldn’t build a fast text editor that could compare to native ones. VS Code came and it was significantly faster Atom was slow to the point of not being usable to some, while VS Code was perfectly usable. The people wanting vim or Sublime performance were still upset and wrote about it, but vscode was perfectly usable and fast enough for the majority of people. It was indeed held as an example of how to make a performant electron app. Still an electron app, but not absolute slog. Tbh, if you disable all extensions in vscode, it’s still fairly fast, and doesn’t even take that much memory. It’s not as usable without extensions though.
I compared NP++ to VS Code at the time. VS Code was nice to use, but it was slower. It was faster than Visual Studio, but that's because VS Code without extensions didn't have language support, etc like VS did.
I find it odd you see otherwise.
And VS 2026 is faster than VS Code these days, now that they spent time optimizing it.
I'm fairly sure VS low performance and responsiveness is caused by their use of WPF for the UI. Never seen a single responsive application written in that toolkit, it's even worse than electron. Not surprised it hasn't taken off outside of enterprises.
It used to be fast before 2010, when they used MFC (or something very similar to it, I don't remember anymore), compiled to native code.
I was using Vim at the time, so didn't get into those discussions. The thing that hurt me was Spotify. They had some other HTMLish desktop app before Electron that was just as bad for memory.
I think you may be right, but I think that actually enforces GP's point: if discussion was about how "a properly tuned electron could be fast", that implies an unstated general belief that electron is slow. In other words, since the time vs code was launched there was indeed a belief that electron was slow (compared to native apps).
Actually I think "properly tuned" sounds like weasel words, a no true scotsman fallacy. "Oh electron is slow? Well, it is slow, but that's not real electron, see if you were doing things the right way it would be fast"
It just means Electron has bad default settings, it's hard to optimize and you might need to move some parts into C++ if you want good performance. Really the same thing as Unreal Engine, there are absolutely fast games made with it but most are super resource heavy.
It means that you need a trillion-dollar company spending millions of man-hours to optimize the performance, using every trick in the book, and inventing a few new ones to deliver one optimized Electron product
> 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.
Article mentions they chose not to use windows native tech (WinUI), presumably for portability reasons. I have no idea how much work it would take to port the Rust client to other platforms, though. Maybe the same code already builds everywhere?
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.
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
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.
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).
That’s what we’re trying to do with Slint (I work on it): a declarative, reactive UI like React, with the logic in Rust, C++, JS or Python. It needs no browser engine, so it uses a fraction of Electron’s memory.
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.
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.
When they can all share the same Electron implementation instead of individual copies it reduces memory quite a bit. I'm not trying to defend Electron way of development but I can see why they pushed WebView2.
What an insane take. Also, the parent comment is incorrect, because the WebView2 memory is clearly attributed for both Teams and new Outlook in Task Manager.
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.
...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).
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.
When it comes to content you control it's very possible to handle everything with platform-native acceleration, but how would you approach embedding a, let's say, YouTube or a Twitter video in a native desktop client?
There’s still native ways to do this with libs. Browsers themselves use these. Plus, we used to embed explorer or WebKit or html or whatever without dragging in a whole giant thing where need be.
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.
No. Even windows' own task manager is not that fast. I don't think that most software most people use everyday on windows was built with strong focus on performance.
The old System Shock 2 is an inspiration for my own loading times. Launching the game instantly shows the main menu with your last save paused in the background. Clicking Play actually unpauses the game. There's no loading time and no process as far as a player is concerned.
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.
Probably at the edge of being a good example. I recently switched to zed because of how bloated VS Code is becoming. I think it gained it’s momentum by being small, but enshitification seems to come for all software.
No it isn't. It takes over 1 GB of memory just to open up a handful of source code files that each are under 1 MB in size (and which, for reference, Sublime can open with 300 MB used). It's an absolute pig.
It has seen (major) optimization work, and it's still quite memory-heavy, although that's probably fine for a rich IDE. But it's not fine for many other apps.
Rich IDE is not something you achieve by slapping a few extensions on an editor. It's in the name - Integrated. It means that there's a GUI designer which is aware of local classes, inspector at runtime which can jump into the right areas of code, performance analysis that gets populated during runs, highlighting and compilation that's aware of the currently selected configuration, etc. There's an extension a few of those, but they're mostly independent and isolated.
At least comparing to Eclipse in terms of Java support, VSCode is still way behind. I've been using it almost exclusively for maybe a year, since I was mostly working on JS and Groovy code, but now went back doing Java dev on Eclipse, and it is a significant difference.
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.
I agree. The lack of native user interface controls for accessing menus and the inability for them to properly track focus for keyboard usage for right clicking (for example) makes them really difficult to use. You have to use the mouse for everything.
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.
"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.
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.
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?
Windows IMEs used to emulate the style of edit control to display its candidate text, and the guess was frequently wrong. That's hardly a new problem for East Asian.
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.
> you can now ship cross platform apps quickly, without electron.
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.
Because any kind of budget, resources are always finite? 2x the tokens roughly translates to 2x the cost. That’s a pretty big ask. Quality alone, unfortunately, isn’t always enough to justify it. There has to be business value too.
With Tauri you have to support multiple web engines. It uses webkitgtk on linux - which has its own set of issues, including being somewhat behind chromium/firefox in terms of stability/security/performance/features...
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.
Discord isn't really the model to follow here, IMO. They killed their native Android app and moved to React Native, and now they're dropping React Native (while mobile somehow keeps "native UI", according to their CTO's tweet). If they wanted to maximize code reuse and accelerate feature development, they should have instead considered Kotlin Multiplatform, then they could've skipped the React Native detour while actually building apps that are native to the platform. (Rust and its cacophony of UI frameworks are not really platform-native anywhere, as far as I'm aware. Maybe Pop OS, but I don't know anyone targeting that specifically.)
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?
Mobile UIs are different enough and, these days, easy enough to construct that to my mind there isn’t much value in the cross platform UI proposition these days. But logic? Sure.
Have you used Kotlin Multiplatform? I currently am and while it sounds great, it's nowhere near ready. Something as simple as scanning a QR code has been a week-long project - the Kotlin-only libraries suck, the Java ones don't work on iOS, the only Kotlin Multiplatform one pulled in 500 MB of dependencies (that's final app size, not development files!!).
There was legit a point where I considered embedding a webview just for the QR code scanning screen, but of course, embedding a webview turned out to be a similar mess.
I am not very familiar with Kotlin Multiplatform, but couldn't you use a Swift/Objective C library for iOS, while using a Kotlin library for Android? What would be the blocker to this?
There's no blocker, but that's not a comparable development experience to more mature cross-platform toolkits.
I now have a separate QR scanning implementation for three platforms and a bunch of if statements in the Gradle files. It took 4x as much effort (once for each platform, plus the work to tie it all together) and now I also need to know how to develop for those platforms, which is exactly what I wanted to avoid by picking a cross-platform toolkit.
This will hopefully improve with time, as it did with RN and Flutter, but my point is that we're simply not there yet.
I'm 100% on this since Electron is probably the worst thing that happened to the desktop development.
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.
Because most of the recent improvements on correctness and 'memory' are from harnesses, my guess is that you want to iterate and test quickly on the software that seems to improve the most and differentiate your brand best. Once a harness is 'complete' (which might happen for specific harnesses, but probably never for code), the team might start to optimise it with compiled languages.
The problem is that they never reach this point where they put it into native code. So you always have a plethora of JavaScript and Python files littering your system. It's baffling.
333 comments
[ 0.21 ms ] story [ 16.9 ms ] threadElectron'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.
"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 don't see how reusing web code is an advantage. Web code is for the web. We are talking about a native platform (Windows 11) which has a mature API platform stretching back decades. Why would you need to make it "web"?
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.
1. Use the make everything bigger/font size settings to change the size of what I currently can't see
2. Restart
3. Open every application I need, and go through every major feature in each of them to determine if I can still see things comfortably, while making sure no elements have exploded in size as this also leads to usability problems
4. If not, go to 1
I have to do this every time I install a new application, or one of them updates and changes their UI or decides to opt into the Windows accessibility settings. The latter one happened a few years ago with Firefox, and cost me a day to sort.
Invariably, it leads me to compromising on what I can and can't see.
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.
Luckily in the modern era we have invented language models, which allow us to expend vast resources on text generation instead.
I dunno if you've been living under an enormous rock, but they used AI to make this.
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.
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>.
> 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...
I'm very excited to see GPUI extended for general purpose usages in the future.
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.
People get too hung up on package managers. When you're building your own proprietary you don't really need a package manager, you just need a central place to download the tarballs from. Or you could do a monorepo and just build everything locally - in 2012, that means you start your build before you leave Friday afternoon, and when you come back Monday, everything's built.
The hard part of all webcam libraries is all the different webcams running all their different proprietary protocols.
It's not that difficult to write cross platform C++ code. Consuming the dependency is always painful. What build system does it use? What compilers does it support? How do you get the code? There is 0 standardization for these things.
C++ code isn't always that portable either. Old code in a new compiler is very likely to break on warnings, especially if the old code made the high quality decision to hard code -Werror in their build system.
From personal experience Rust as a package and ecosystem is far more portable than C++.
The only reason why a cross platform well supported C++ package/module isn't available is because nobody has bothered to build it.
If it really is something that bugs you then be the one to do it, throw your clanker of choice at it and integrate it into a project you run in production.
"Chromium ahips with it" isn't a valid excuse these days, that is likely an hour or two away with a modern LLM, building and packaging electron is more work.
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.
[1] https://www.formdev.com/flatlaf/
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/
How outrageous to demand that a software developer possesses the 'special skills' to ship a Qt application. It's not surprising that people think AI is killing programmers when this is the level the average 'programmer' has been operating at for 15+ years.
Imagine going to a chef and he tells you he can only warm up microwave lasagna because cooking the steak correctly requires special skills. The special skills are your job
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.
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.
Certainly, if you write a native UI for every platform, you're going to need a few more people because you have to have someone who understands each platform. However, with a little bit of work you can define some good interfaces to that UI and most of your needs are going to be things that are not the UI framework but they're logic that can be cross-platform.
What cross-platform frameworks give you more than the UI is all the other pieces you need. I've written a bunch of applications in Qt Core with no UI at all because it's so convenient to have those Qt abstractions.
>>you're going to need a few more people because you have to have someone who understands each platform.
a big no here.
That was absolutely not the case at all. At least not on HN or twitter. It was for Chief Complaints for Atom. When VS Code first launched everyone was suggesting how much faster it was compared to Atom. And how a properly tuned Electron Apps could be fast. And Microsoft promised it will get even faster that makes everyone excited.
The only few of us who were complaining was how could everyone judge this to be fast when we have Sublime. And that was even before Sublime had GPU rendering.
I find it odd you see otherwise.
And VS 2026 is faster than VS Code these days, now that they spent time optimizing it.
It used to be fast before 2010, when they used MFC (or something very similar to it, I don't remember anymore), compiled to native code.
>This article does nothing to address that.
Article mentions they chose not to use windows native tech (WinUI), presumably for portability reasons. I have no idea how much work it would take to port the Rust client to other platforms, though. Maybe the same code already builds everywhere?
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.
To me it seems like all frameworks and apps use much more memory than 10 years ago, but don't really offer more features.
Maybe a really young GPUI still has limitations, but I doubt it would suddenly need to use 5x as much memory if you added them.
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.
Also, pro tip, you can still just use it in browser. I hope that doesn't go away.
https://github.com/zed-industries/zed/discussions/17212
I don't know if we have a winner here.
[1]: https://taskslinger.net/
If you are asking this kind of question you have already lost the plot. You don't need a "tech stack".
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.
Also, first time I'm hearing about Monaco. I thought VSCode was an Atom fork.
https://github.com/Sidenai/sidex
There's only 0.7% Rust code and not even any C++. And almost all of that Rust code is for the CLI, not the editor.
The rest is just plain TypeScript and other web technologies.
Also the performance improvements on the bultin terminal thanks to using WebGL as if it was a native app.
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.
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?
[1] https://accesskit.dev/
[2] https://github.com/zed-industries/zed/blob/main/crates/gpui/...
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 the GPUI approach is still finite tokens, just better stack.
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?
https://mozilla.github.io/uniffi-rs/latest/
Mobile UIs are different enough and, these days, easy enough to construct that to my mind there isn’t much value in the cross platform UI proposition these days. But logic? Sure.
There was legit a point where I considered embedding a webview just for the QR code scanning screen, but of course, embedding a webview turned out to be a similar mess.
I now have a separate QR scanning implementation for three platforms and a bunch of if statements in the Gradle files. It took 4x as much effort (once for each platform, plus the work to tie it all together) and now I also need to know how to develop for those platforms, which is exactly what I wanted to avoid by picking a cross-platform toolkit.
This will hopefully improve with time, as it did with RN and Flutter, but my point is that we're simply not there yet.
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.
Discord is probably my least favorite thing to happen to chatting online, but for some reason it's what everyone wants to fucking use.
Slapping a few million lines of AI generated slop code ought to do it for instance.