I am at the opposite extreme. We should ditch electron and use browsers good enough integrated they can run all the apps with native feel and reusing the same engine (not a lacklustre OS webview but a complete one) This solves the memory overhead, solves unpatched or misconfigured chromium in each electron app as well as portability and reusing web dev skills. Also this would allow permissions and security to be managed by a layer that can focus on that and I don't have to worry about what a native app can do. (OS permissions and sandboxing are just not made for vibecoded infinite software and likely never will catch up) All the performance and other arguments are just not true, a well build webapp is often more performant than a native app especially for long scroll lists not even to mention accessibilty, extensions and more. I will never trust discord or Spotify to run something natively on my machine and so should no one else.
How's that different? You are still shipping a web browser and rendering through the inefficiency of the DOM event/rendering model. Sure it helps that the business logic is written in a native language, but modern, JIT-ed JS isn't a sloth either, and I don't think that's what people have gripes with and what causes abnormally large runtimes.
> Essentially. you do not ship a browser in Tauri.
I mean, essentially you are? It just so happens that this web browser that your application very much runs on top of may link (to a more or less large extent) with the host OS "WebView"/built-in browser (assuming there's one to begin with). My point still stands: if you are lucky, you may save some on the binary size download, once, but the run time is a web app with all the quirks and inefficiencies of the web as a platform.
> All the performance and other arguments are just not true, a well build webapp is often more performant than a native app especially for long scroll lists not even to mention accessibilty, extensions and more.
A well built web app will never be more performance than a well built native app.
It's just inherent due to the JavaScript abstraction.
Never? We already had this discussion about JVM, and we know for a fact that it's possible for JIT to achieve better performance with that damned bytecode compared to natively compiled equivalent.
Let's not move the goalposts, the word in question is "performant".
Though even with memory it's not as clear as you assume in the context (which is about browser-based apps). Singular C/Zig/Rust program will surely be more economical than a singular in-browser app due to browser itself having a huge footprint. But what if said user has that browser open all the time anyway as probably most users do? What if there are more than one GUI-rich app, and with browser they share most of the overhead? PLs which allow low-level optimizations offer great opportunities, no arguing. But never say "never" until you know what exact problem yiu have to deal with.
> Let's not move the goalposts, the word in question is "performant".
Even though the word performance was used by a parent comment, I think they used it as an umbrella term. The article and most of the talk around rust discord is primarily about the memory. And JVM is probably the worst runtime you could pick if you care about memory usage.
Assuming this would make this comment less reasonable though. Optimization for memory usage is distinct from optimization for performance in our craft. And it's pretty basic thing.
Rust-based Discord achieves both, though... You can absolutely get an application to run faster while using less memory, given there's enough low-hanging fruit (and with today's software, there certainly is...).
If you're optimizing sorting algorithms, video decoding or compression software, then that's another story, because using more memory can trade time complexity for space complexity in your algorithm (i.e. Merge Sort vs Insertion Sort).
It's true that JavaScript costs, but the text renderer in Chrome is just wildly optimized and definitely can outperform an OS list view. An article here on HN covered it a while back.
> the text renderer in Chrome is just wildly optimized and definitely can outperform an OS list view.
The question is not whether it can win against GTK/Cocoa/WinUI but whether it's faster than other retained-mode renderers such as the one Discord is using, GPUI.
Also, even if just running on a browser tab, each tab has a lot of memory overhead compare to what an actual binary running on the OS has. That's memory that gets wasted from the outset, before the developer even writes a single line of JavaScript.
The question is at what cost and at that level of both being optimal does it even matter to the user or is indistinguishable. There will always be 1% native apps that make sense, i'm talking about 99% of applications.
In a way yes, but things like keyboard shortcut, file pickers and similar are major convenience issues and not as easy if the only thing that runs on the metal is a server process, and the UI is limited to the browser. A webview UI like Tauri might solve that (I'm not familiar with it, so I can't say if it does).
I think that's also the main reason software like VS Code is electron based and not browser based.
> well build webapp is often more performant than a native app especially for long scroll lists
A well built anything is better than most software. I would argue that a well built rust app will probably a higher quality piece of software than typescript slop produced by Microsoft.
I created my own declarative react-like UI library that is small, efficient, and does things just the way I want. I have absolutely no desire to go back to the days where for every platform I want to develop for, I need to learn whole new UI paradigm, with all its quirks and gaps and inefficiencies.
Past a certain age, having to do this every year or two get old fast. And, it is not necessary for good performance. The only holding back good performance and capabilities from web apps are the platform vendors.
I agree with this. And even further, I think we wasted a decade or so, forcing web and native apart - especially on mobile. Partly due to Apple building a native moat when we could have put resources into building a more performant and powerful internet.
You can optimize all you want, but if your foundation is a pack of cards, you're not going very far. JavaScript is not a solid foundation to build anything on. It's a language that should have been extinct long ago along with internet explorer. But, people kept trying to save it - adding abstraction on top of abstraction, even languages on top of it (coffeescript, typescript) just to get it to work at the baseline of a decent language. It's the only language that is forced upon us. If browsers gave us options to use other languages, it would and should've been long been dead.
If javascript is not a solid foundation to build anything on, then how come everything is built on top of it? It's the language powering the whole web, and people went really really far with it. Besides that, almost every major programming language can now run in the browser via webassemly, which solves problems in the areas where javascript is lacking raw performace.
What? No, absolutely not. Did you not learn your lesson when google decided to actively try to kill ad blocking? Why on EARTH would I want all of my desktop apps at the mercy of google and chromium?
You can tell me until you're blue in the face that you also think these apps should be cross-browser but we all know that will never happen.
This is whataboutism. There is still firefox as possible second engine impl and you are arguing its better to not have a layer at all than accepting the possibility google might take it away. Plus most people are on macs or windows where there are at least as bad actors playing against them.
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
If we mean native as in OS-specific GUI APIs built-in to the operating system, then yes. All of the browsers are abstractions on top of that. If we mean cross-platform GUI libraries for Rust I think your choices are like Dioxus (a webview), Tauri (also a webview), Slint (draws its own widgets), and maybe Fltk (draws its own widgets) with extensions?
Yes, yes they do. WXDragon for Rust, for example, provides quite good accessibility. And maybe accessibility would be better for frameworks like QT or DearImGUI if (1) people didn't act like the web was some paragon of accessibility (hint: it really, really isn't, not when websites misuse web APIs -- which happens quite frequently) and (2) UI framework developers didn't just make a UI framework that looked sexy but left accessibility on the floor.
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.
The article implies that a11y will exist on launch and maybe already is.
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.
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.
By dialog resource I mean this: https://learn.microsoft.com/en-us/windows/win32/menurc/dialo... it's a DSL (analog of glade) that describes buttons, text boxes and their positions in a window, measured in dialog units, these dialog units are computed from the font size per dialog.
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.
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.
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.
Discord actually launched as a web app, and then moved to adding a desktop app, which has quite obviously become far more popular than visiting discordapp.com and using it in the browser.
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!
> 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 is meant to be a fairly low level library. If you want screenshots check out zed, but be aware that for many use cases you'll have to roll your own widgets.
gpui-kit (formerly gpui-component) provides a richer set of widgets and a Javascript shell. Screenshots can be found here:
I don't know about you but I _want_ all UIs to look identical - specifically I want them to look like they belong on the platform I use, not the fever dream of some product person.
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.
The article says they can use the Rust code with wasm as the iOS app and that includes iPad and Android. And Mint is just Linux so it should run fine, just like Zed.
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 was not "bad default settings", like often with UE5, it was "MS did a superb job making VSCode not dog slow like Atom" and it took really lots of work
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?
> Electron's value prop has always been about having one team producing one app that is supported on multiple platforms with minimal additional effort.
Which is an assumption that made sense pre-2026. It no longer makes sense anymore. Since you can produce multiple apps, one per platform, with minimal additional effort now.
> Electron's value prop has always been about having one team producing one app that is supported on multiple platforms with minimal additional effort.
I have only ever worked as a software engineer in mega corps, so my perspective is understandably limited. The value prop that I have observed with Electron is that average JavaScript/TypeScript programmers are cheaper than average Java and C++ programmers. As a result, it can be cheaper to build and maintain JavaScript/TypeScript apps on Electron. To be clear, for years before Electron arrived, it had already been possible to write internal, cross-platform corporate apps using Java (Swing) and C++ (Qt). Also, senior technical management was happy to add RAM to desktop PCs to deal with higher memory requirements for Electron apps. Since the RAM apocalypse, maybe this cost savings has been offset. Still, most corporate desktops are way overpowered (RAM/CPU/GPU) for what normie users need.
I don't understand the hate on Electron. I think most people here never shipped cross plattform apps ever and even less maintained them across cross platform. It's a financial decision.
Electron (in the age before AI) enabled to stand on the shoulders of giants to build a reliable product with one code-base among many OSes. Something which Java promised Electron really delivered for most end-user apps. Google poured billions into making the fundament of Electron fast and reliable and bugfree. And it enabled many Linux ports of apps which would have otherwise not happened.
Best example is vscode.
Are Electron apps more wasteful than native: sure. But I rather stand with Electron and that Windows, Mac and Linux is supported.
But electron applications that are forced by the first party (IE; third party clients are explicitly forbidden and will be an EULA violation- possibly resulting in expulsion from the platform) is an issue.
We talk about a global RAM crisis now due to AI, but I don't even want to think about how much RAM is hoarded by Teams/Slack and Discord in aggregate- these are applications that are intended to be run in the background by everybody, so you're talking at least 2GiB per person because you can be pretty sure that people are running more than one of these.
1.5GiB * the number of people in work = what.. 150 petabytes of RAM in Europe alone? For chat.
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.
People need to understand even a 70% smaller 290MB GUI app is still terrible. We could open 200 browser tabs on Windows 2000 with only 256MB memory back in the days. Discord should not consume more data than 200 browser tabs.
this is true, I even remember one of the first alternative clients for Discord (Ripcord IIRC) was orders of magnitude more performant and lightweight that this rust rewrite.
I'm pretty sure my Pentium 3 PC back in the day had 128 or 256MB memory, and I ran tabbed Mozilla/Seamonkey as well as the first versions of Firefox ("Phoenix"), both with tabs. 2003ish.
Cold Phoenix start on Windows XP was similar to Firefox startup today on a Mac :D (ok, maybe a few seconds longer of pegging the CPU)
Opera and Firefox, "actually" (along with some lesser-known browsers), introduced tabs around the same time as, or very soon after, the launch of Windows 2000.
Alternatively, read "tabs" as "windows" - we know the word "tabs" is not the important point of that post (and that the number 200 is exaggerating for effect). Right clicking a link and selecting "open in new window" opened a new window in the same browser instance, not a separate instance, although there wouldn't be any visual difference.
> People need to understand even a 70% smaller 290MB GUI app is still terrible
I don't understand that kind of reasoning.
Electron - and anything web - has allowed us to basically solve distribution and iterate at lightning speeds and people are getting bothered because an application in 2026 takes multiple amounts of RAM than the their favourite 90s app?
Come now, the average laptop has a ton of memory and fast i/o to be able to not care even if that 290MB was 1290MB.
The trade off of higher memory for some middleware is totally worth it.
Software developers need to realize that their app is not the only one that will be running on the user's computer. A single app taking 300 MB of RAM? No problem. 20 apps? That's already 6 GB of RAM.
And keep in mind we're talking about a damn chat client, not some complex video editing or CAD app.
> Software developers need to realize that their app is not the only one that will be running on the user's computer
The user will need to realize that, and if they don't like it they will close the app and move to a different provider. But that of course will not happen because no matter how the IT people want everyone else to use their xmpp xfce clients or whatever; Slack will always triumph because it is not just a "damn chat client"
> 20 apps? That's already 6 GB of RAM.
No one runs 20 apps in the foreground, my finance runs gsheets, xero and the erp all of which are webkit. The lenovo's were the cheapest ones I could get with 8gb ddr4 and still no one has complained about slack or our erp written in react not being responsive enough.
I understand that people like to constrain themselves for creative reasons but lets not be cheap with resources.
Do you honestly consider this normal? In the 00s I've used to run Windows XP (which was derided as an absolute pig -- what the hell did we know) + Delphi with a GUI designer in it much more advanced than anything we have now + 1-2 PDFs + a web browser with maybe 5-10 tabs + often a chat client in the background (usually QIP -- it supported not just one protocol like Slack, but about a dozen of them, and could send and show multimedia messages in addition to text).
Sometimes also a music player. All of this relatively comfortably fit in 128 MiB of RAM; it was really comfortable once I moved to 512 a few years later, and I thought that should be enough for the decades ahead.
But then we got electron and turning the web into an operating system on top of an operating system.
Now having a document processor barely fit within 8 GiB is considered acceptable...
Normal or not that's how it is. The incentives are not there and the network effects close the casket...
Is it regrettable? Idk. Definitely not unique to software though once you look and appliances, cars etc - they are not optimized for the things I prefer they would have been.
I recently installed "dvdisaster" from Debian. The provided version has the GUI disabled, on the grounds that it's written in GTK2. It's just a single-line configuration change, so I recompiled with the GUI enabled.
It's been a long time since I last used GTK2. I was shocked at how much faster it feels than GTK3/GTK4 apps. Load time is almost instant on my old computer, and no perceptible latency anywhere. There's no arbitrary 60fps frame rate cap like with more recent GTK versions (while running on Xorg). There are no annoying animations. GTK2 was already perfect and everything since then has been a downgrade.
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.
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?
oof. No proper support for IMEs is a huge non-starter for East Asia. Why don't they just use OS standard text renderers like everything before Rust?
Or is Discord planning to implement their own forks of existing IMEs into the app? Don't tell me they are going to just put in a tiny LLM and call it a day...
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.
What worries me is that there's a general atmosphere that LLMs solved all NLP tasks, despite they don't do so well for kanji pronunciation <-> text mappings, likely for the lack of data - Japanese users especially don't post enough of organic data useful for that, apparently. Discord may be in a "good" spot to be able to (very invasively) collect that data by setting up a keylogger and comparing that to the final user-submitted text, but (aside from all the concerns) I'm not very hopeful about it.
This is definitely true. It seems to be the modern approach that the less effort in development, the better!
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.
Not a front end developer but I’ve always assumed it was ROI - nobody felt a smaller memory footprint would drive enough incremental revenue to offset the costs, compared to the other things they could be doing.
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.
Mature was probably not the best word. The modern desktop UI toolkits produce a better UX to me.
Qt feels too locked in to old decisions that were the right choice at the time, but desktops and mobile have changed so much that it always feels like a clash of old and new.
You can make Qt look however you want. The point is that it will give you native UI by default (for the most part and excluding QML)
That native UI will be faster than Electron and most other retained UI toolkits and will be just as capable of creating whatever your subjective view of “modern UI” is.
I'm still waiting for a single Qt-based app on macOS that feels like a macOS app. They look more like some Windows 95-era app wearing the Aqua skin peeled off the carcass of some slightly older-and-definitely-not-current version of macOS.
Don't confuse UI and UX. You can make Qt have the right UI, you can't make it have the right UX.
This is also why electron and other frameworks really devalue MacOS. Back in the day anything not built with Cocoa felt off, there was a difference in usability.
Now we take it for granted, and Mac apps feel as good or bad as everywhere else.
I haven't seen what you describe, even if it's theoretically possible. I'd really love to be shown an example.
I'm not saying it can't happen, and in fact, if it existed I wouldn't have noticed (I mean, the point is that you think it's native, so I wouldn't have noticed..) but I can't think of an example and I would love to see one.
Qt licensing is terrible for commercial products. You end up with an account manager that changes every year, compliance within your company is a chore. Qt is fine for things that are and always will be open source.
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.
One good reason: extensibility. Pi is extremely malleable in ways that would probably be harder to achieve if it were in, say, Rust.
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.
I guess it depends on the harness, for example: chatgpt.exe right now is 1 GB on my windows machine. peseo.exe is 500 mb. and opencode.exe + bun.exe is 300 mb.
This is why I like Kotlin (or Java). You can get the extensibility of Python/JS at native speeds and full multi-threading, with fast compile speeds. It does use more memory compared to Rust though.
chatgpt.exe right now is 1 GB on my windows machine. I have 16 GB and can spare none. So I don't think that nobody cares about such performance increases.
Most don't care or ever notice these things. Hacker News crowd does and always has, but the a non-technical user of a run-of-the-mill desktop app would rather have new features, and maybe some bug fixes, over performance.
Myself? I care. I regularly run a project that needs 6GB for the language server to provide type hints.
> but the a non-technical user of a run-of-the-mill desktop app would rather have new features, and maybe some bug fixes, over performance.
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.
One possible reasons is that all of those are compiled languages vs interpreted. It doesn’t sound like much but compiling your code for three plus platforms and distributing binaries adds just enough complexity and friction to make it feel a lot more difficult.
Modern CI systems have no problem building for 15 or 20 different platforms is what you need. There's a little bit of hassle of distributing binaries but again it's not a big deal for anyone who actually puts their mind to it.
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.
Personally with LLMs now, I don't actually see a reason for dynamic languages at all. LLM now makes it faster so python, js and similar are fully redundant. It's all just inertia for now
Every time I start the discord app, it downloads updates. It was never the case when I opened discord app and it didn't start updating. Updating 7/13. Updating 1/4. There is always some update pushed, I think almost every day. Comparing the launch times of fully updated clients is kinda useless, as it will always take few minutes to update anyway when you are cold-starting it. Slow electron apps are just a skill issue. Yes it has a browser overhead, and it will use a bit more RAM, but the bare-minimum time required to spin up the underlying Chromium shell and Nodejs runtime environment is 100-300ms, everything on top of it is just application overhead aka skill issue. My slack client opens almost instantly all the time, and it's as responsive as any native application around, sometimes even greatly more responsive than some native apps made by Apple.
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.
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.
Well, why not just move on from Windows and transition to Linux, as I did with CachyOS earlier few days ago. Doesn't even want to look back on Windows now since everything is so smooth and uses half the memory I needed compared to the equivalent in Windows! The only quirk I have is the xe driver that after suspension and resume the GPU may go haywire and I have to restart SDDM but I switched from S3 to S2 sleep and the problem seems to be worked around. I'm using an Arc Pro B50 so not sure if that's buggy on Linux whatsoever but it is metric tons better in Windows.
So what exactly does any of that have to do with switching ann application off of Electron, aside from Windows being in the headlines which makes sense given the site is “windowslatest.com”?
i believe that primary issue of electron is also that the framework consumes RAM/resources which is already a issue especially for windows which is a heavy OS on the RAM. the same side is visible on the Linux speciapic app ends of applications like VS code. they have poor integration , Loads of resource consumption and minimal polish
I really dont understand why when AI is available, big company still using electron for their apps. Codex was written in pure swift on macOS and right now moved to Electron again
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.
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.
for a team that was using the underlying stack (other than the ui library) for other components, trying this is a low-hanging fruit of an experiment. this should not automatically become the recommendation for everybody. (yes i do hate electron apps)
for a large project like electron, it is up to the maintainers to optimize it while preserving the api. if they can do this with typescript, they can also explore this with electron. perhaps a native webview option instead of chromium?
with current memory crisis, devs with cushy performant laptops bought over a year ago should realize that we yet again have hardware constraints and need to act accordingly. however, putting the pressure at the wrong place is not as productive.
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).
edit: Avalonia is quite mature, with accessibility to boot.
I have seen this assumption in recent GUI threads here (More so your upper post): Building a PC application is not equivalent to building a web browser. A web browser is a type of PC application built for a specific (But very broad!) use. I didn't think I would need to write this statement/distinction, but I have here. Web languages, culture, and syntax have not been a value add to PC application development. Electron is the clearest example why. My model is that is the value add of Electron: Appealing to web devs through language and culture.
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 think anyone likes the look of Qt more than what you can achieve with webapps in terms of UI
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.
> 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)
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.
Listen! The fact is, JavaScript/HTML/CSS are a holy cow, and the Web is a religion. And you will come up with any excuse just to protect your holy temple.
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.
What I don't get is why most background electron/CEF applications don't unload the web engine when it's minimized to tray for some time. Chrome starts in about a second, the the webview shouldn't take more than that to re-initialize.
Is that a whole UI re-write in a native/non-web framework? Because in case that's not, this is still running in a browser, i.e. it stands at 80% or so of the bloat factor of electron, and what makes it faster is possibly (mainly?) that they haven't gotten yet to adding as much stuff as seen on the regular client.
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.
Theres a small subset of apps where I still think electron can sort of be worth it, but its definitely never any of the always active or second monitor apps like we often end up seeing. I think an app you dont mind closing when youre done, and that doesnt expect or require to be run alongside other demandind apps, could potentially be worth building with Electron. But that is sadly not the category of apps that are often built with it.
I hope it's a tremendous success that inspires every app to rebuild native. We've been in the dark ages of desktop apps with 200ms click response times and 15hz rendering, 30 second load times despite having a super computer worth of hardware on every desktop.
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.
I think the reason why web technologies that are essentially being ported to desktop is not only because they provide cross-platform compatibility (still lacking a standardization on Linux), but they tremendously helped the hustle culture built around the motto of "ship it fast" by providing the fastest iterations and benefiting from already existing cheap pool of web developers, especially via outsourcing/offshoring.
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.
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 also noticed that the "smoothness", when everything feels quicker, is immediately noticeable on desktop (vs laptop), all apps, several laptops (Mac, Thinkpad, Framework).
I find it surprising that they are still investing in performance improvements, because to me for a while now it looked like discord has entered the enshitification stage of life, where they go purely for maximizing profits with no regard for user experience. As they had recently hit the news with their age verification requirements I thought that it's over for discord as they will start limiting the users and selling their data en masse.
Discord always deeply cared about their users. Which is why nobody is able to get even close to replacing them.
They are adding user requested features and improvements all the time. They might not be what you consider "improvement", but maybe you are not really their target market.
Discord is my favorite thing to happen to chatting online. It combined everything useful from IRC, Skype and TeamSpeak, in one application and with modern UI, and things we now take for granted like attachments and link embeds. And even 10 years later, there are still no alternatives that aren't just discord but worse.
This gave me a good laugh. Like, who could have known?
There's absolutely no reason why a simple chat client should take more than a fraction of a second to start. If you need to fetch data from the web, just do it progressively. Not to mention that 290 MB is still way too much.
It's ridiculous how over the last 20 years simple apps became slower and slower while computers became faster and faster.
At the same time, REAPER (a full digital audio workstation) opens in less than a second.
These so-called software engineers seem to have completely lost the baseline of what is possible on modern computers. Or they just don't care.
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?
If LLMs are truly driving the cost of "writing code" down to zero, then we shouldn't need Electron anymore. The whining from developers about how it's soooooo hard to write and maintain N separate native applications is no longer valid. Point an LLM at your existing Electron code base and have it fork off a bunch of native ports of it. LLMs are surprisingly good at matching the functionality of existing software. Keep and maintain the Electron app as an internal reference design (your developers probably only know JavaScript anyway) and "build" all your actual production releases from that.
One thing Electron has over Tauri for Discords case is WebRTC. I tried making an open source alternative using Tauri and got plenty far, then I learned that WebRTC on Linux is not OOTB since its still experimental. Webkit on Linux requires WebkitGTK, so everything under the sun out there that had “webviews” cross-platform cannot do WebRTC ootb.
At least now Discord will consume your GPU vram while you game.
I think I wound up hacking something in Rust which is less than ideal felt hackish, at that point I was better off just remaking the UI in an actual native UI stack.
For me the ugliest part of Electron is that it uses client-server model inside a program and includes both a browser and Node.JS. This is so stupid. If you love microservices so much why don't you put every React component in a separate process?
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.
Back in the day, Microsoft got into trouble for shipping a free browser together with its OS (https://xkcd.com/1118/). Somehow I wasn't expecting 'every app ships its own browser' to be the solution.
To be fair, multi-platform GUI development is _hard_ to do properly, just look at the differences between menu bars on Windows and Mac OS. In theory you could ship electron once as a dependency, similar to the various MSVC++ runtimes, but then you've reinvented 'dll hell'.
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.
I’m disappointed to see the continued proliferation of JavaScript and TypeScript. I cannot fathom why people are using these garbage languages still when we have so much better options and code is essentially free now.
These languages were developed for hypertext. Discord is hypertext. The question is why Rust or C++ or anything would be so suitable for developing chat rooms; it’s not even clear why JavaScript would necessarily be slower after being statically compiled.
Yes, the first one is not required and shouldn’t be used, write your own leftpad then. The second is about as awful as getting NaN, which is to say not, and can be overridden in the prototype anyway if you want more casual logging.
So Discord rediscovered that native apps are faster? Until fairly recently, every proper desktop "app" was written in C/C++. In other news, water is wet.
Hot take, but: love electron. Write once, runs anywhere. The majority of bugs aren't platform specific. Easy to get nice visuals that stay consistent across different OS. Yes, it's not native. I don't care. It's not a painting to be admired. The focus on looks and visuals versus usability and ux is a plague.
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.
> Yeah, it takes some extra ram. Fork my stuff and rewrite it in rust if you care. I don't.
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.
It's the other way around though. A lot of times, it's spending system resources so that they can use something that will run on your OS. Most apps using electron wouldn't have linux versions if electron wasn't a thing.
That doesn't mean you can't use something better when that comes along. Using these new Rust GUI frameworks is basically the same as electron, you use rust instead of web tech.
This approach isn't groundbreaking, QT framework does this commercially for the past few decades. AI has just made it easier to manage & migrate.
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.
"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.
Many people dislike Electron, but there's a reason it's still widely chosen. It runs on Linux, macOS, and Windows. With C++ or C#, you have to build differently each time, and cross-platform support is difficult. And fundamentally, it brings over web syntax as-is more than other frameworks, making front-end styling convenient.
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.
because native apps aren't slow. Businesses didn't want to spend money on redundant effort replicating the same feature for each platform. No matter how efficiently you use electron, it is fundamentally a browser and server in a strait jacket pretending to be app. That's why it's bloated/inefficient. The JS framework used in negligible in comparison.
Not as efficient as native, sure. But have you actually tested it?
If browsers were inherently slow why do plain HTML+CSS pages (no JS) run nicely? Then consider the fact that modern JS runtimes are competitive with ART (native Java/Kotlin apps on Android). Where is the main source of inefficiency?
Browsers are just another runtime - you can write inefficient code in anything, even native.
> 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'm not directing this at you, but to all developers using Electron and its ilk:
Show some empathy for your users and shoulder that cognitive load so that your users can have their hardware back. That's just courtesy, and a responsibility a good engineer takes on. There are so many more users than there are of you, their aggregate gain from your efficient software far outweighs whatever extra work is necessary to do the decent thing.
I don't think you're wrong. But there's a limit to the languages and technologies a person can learn. In that sense, Electron is efficient. Just as a product doesn't necessarily win just because it has better performance.
OR you can use Lazarus pascal and ship a 5mb application that uses 13Mb of RAM and runs everywhere instead of a 150MB installer that installs the nth multigb copy of the same application with different hat that leaves free 13Mb of RAM.
https://github.com/alainnothere/mailBoy
Electron apps are a disease.
BUT BUT THEY LOOK GREAT, LOOKING GREAT SHOULD COST 1000$ OF RAM BUGA BUGA...
I think this article is misleading, you can use any framework to make slow bloated software. A great thing about Electron and similar projects is that you get one codebase which is useable on many different platforms. An Electron application can easily be a website and PWA, then the user can choose what they prefer.
A good example fast / "performant" software which uses Electron is Obsidian.
Yes Electron isn't perfect, but I think it's a good choice for many situations. Same for Tauri, CapacitorJS, etc. Regardless of which is chosen, there should be an effort to make software performant and non-bloated.
I am at the opposite extreme. We should ditch electron and use browsers good enough integrated they can run all the apps with native feel and reusing the same engine (not a lacklustre OS webview but a complete one) This solves the memory overhead, solves unpatched or misconfigured chromium in each electron app as well as portability and reusing web dev skills. Also this would allow permissions and security to be managed by a layer that can focus on that and I don't have to worry about what a native app can do. (OS permissions and sandboxing are just not made for vibecoded infinite software and likely never will catch up) All the performance and other arguments are just not true, a well build webapp is often more performant than a native app especially for long scroll lists not even to mention accessibilty, extensions and more. I will never trust discord or Spotify to run something natively on my machine and so should no one else.
I just run discord in the browser.
The native one reads the titles of open windows on your desktop, and God knows what else.
(Well, I don't use discord at all anymore, but I very intentionally never used the desktop app.)
It’s gotta be to enable screen sharing, so the use can see the title of windows within the app, right? Although the OS should sandbox that away
Not sure who's still using electron...Rust + Tauri is pretty much standard these days.
I wish I could agree but Tauri performance is insanely bad on Linux.
I think it'll be fixed soon but it drives me nuts.
Flutter is under appreciated for desktop.
what metrics drive you nuts ?
Dioxus has many renderers and also cross-platform.
https://github.com/DioxusLabs/dioxus#experimental-native-ren...
Blitz itself is a great experiment in debloating.
see also https://github.com/pathscale/izumo
How's that different? You are still shipping a web browser and rendering through the inefficiency of the DOM event/rendering model. Sure it helps that the business logic is written in a native language, but modern, JIT-ed JS isn't a sloth either, and I don't think that's what people have gripes with and what causes abnormally large runtimes.
there's a lot of difference, please just look it up in any AI. Essentially, you do not ship a browser in Tauri.
> Essentially. you do not ship a browser in Tauri.
I mean, essentially you are? It just so happens that this web browser that your application very much runs on top of may link (to a more or less large extent) with the host OS "WebView"/built-in browser (assuming there's one to begin with). My point still stands: if you are lucky, you may save some on the binary size download, once, but the run time is a web app with all the quirks and inefficiencies of the web as a platform.
The security boundary here is difficult, if you intend to integrate with native workflows.
Also difficult to manage fake websites duplicating the look and feel. Scamming people into giving access or passwords.
A native app which is installed once from a good source is more secure, i feel.
> All the performance and other arguments are just not true, a well build webapp is often more performant than a native app especially for long scroll lists not even to mention accessibilty, extensions and more.
A well built web app will never be more performance than a well built native app. It's just inherent due to the JavaScript abstraction.
Never? We already had this discussion about JVM, and we know for a fact that it's possible for JIT to achieve better performance with that damned bytecode compared to natively compiled equivalent.
It would be extraordinary to see a real world rust program use more memory than its JVM equivalent.
Let's not move the goalposts, the word in question is "performant".
Though even with memory it's not as clear as you assume in the context (which is about browser-based apps). Singular C/Zig/Rust program will surely be more economical than a singular in-browser app due to browser itself having a huge footprint. But what if said user has that browser open all the time anyway as probably most users do? What if there are more than one GUI-rich app, and with browser they share most of the overhead? PLs which allow low-level optimizations offer great opportunities, no arguing. But never say "never" until you know what exact problem yiu have to deal with.
> Let's not move the goalposts, the word in question is "performant".
Even though the word performance was used by a parent comment, I think they used it as an umbrella term. The article and most of the talk around rust discord is primarily about the memory. And JVM is probably the worst runtime you could pick if you care about memory usage.
Assuming this would make this comment less reasonable though. Optimization for memory usage is distinct from optimization for performance in our craft. And it's pretty basic thing.
Rust-based Discord achieves both, though... You can absolutely get an application to run faster while using less memory, given there's enough low-hanging fruit (and with today's software, there certainly is...).
If you're optimizing sorting algorithms, video decoding or compression software, then that's another story, because using more memory can trade time complexity for space complexity in your algorithm (i.e. Merge Sort vs Insertion Sort).
You cannot separate performance from memory usage. Usually less memory usage for apps comes at the cost of performance and vice versa.
And more memory usage can slow down the whole system, because the system may need to swap and compress memory.
To be direct: this is utter nonsence. Memory usage and performance are different targets of optimization, which often at odds with each other.
I have seen it happen once in an LLM rewrite from java to rust. The modern JVM gc is actually pretty good.
Yes never
So fix the JavaScript abstraction. I've had more success with dart-wasm lately so I'm waiting for someone to finish the standards.
It's true that JavaScript costs, but the text renderer in Chrome is just wildly optimized and definitely can outperform an OS list view. An article here on HN covered it a while back.
The question is not whether it can win against GTK/Cocoa/WinUI but whether it's faster than other retained-mode renderers such as the one Discord is using, GPUI.
Also, even if just running on a browser tab, each tab has a lot of memory overhead compare to what an actual binary running on the OS has. That's memory that gets wasted from the outset, before the developer even writes a single line of JavaScript.
Do you have the link to it or remember what it was called?
The question is at what cost and at that level of both being optimal does it even matter to the user or is indistinguishable. There will always be 1% native apps that make sense, i'm talking about 99% of applications.
To be fair, your upthread post does specifically say "all the apps", which could lead readers to assume that you mean to address 100% rather than 99%.
In a way yes, but things like keyboard shortcut, file pickers and similar are major convenience issues and not as easy if the only thing that runs on the metal is a server process, and the UI is limited to the browser. A webview UI like Tauri might solve that (I'm not familiar with it, so I can't say if it does).
I think that's also the main reason software like VS Code is electron based and not browser based.
> well build webapp is often more performant than a native app especially for long scroll lists
A well built anything is better than most software. I would argue that a well built rust app will probably a higher quality piece of software than typescript slop produced by Microsoft.
I'm with you.
I created my own declarative react-like UI library that is small, efficient, and does things just the way I want. I have absolutely no desire to go back to the days where for every platform I want to develop for, I need to learn whole new UI paradigm, with all its quirks and gaps and inefficiencies.
Past a certain age, having to do this every year or two get old fast. And, it is not necessary for good performance. The only holding back good performance and capabilities from web apps are the platform vendors.
Is this library open source? I’m curious about how it works.
I agree with this. And even further, I think we wasted a decade or so, forcing web and native apart - especially on mobile. Partly due to Apple building a native moat when we could have put resources into building a more performant and powerful internet.
You can optimize all you want, but if your foundation is a pack of cards, you're not going very far. JavaScript is not a solid foundation to build anything on. It's a language that should have been extinct long ago along with internet explorer. But, people kept trying to save it - adding abstraction on top of abstraction, even languages on top of it (coffeescript, typescript) just to get it to work at the baseline of a decent language. It's the only language that is forced upon us. If browsers gave us options to use other languages, it would and should've been long been dead.
If javascript is not a solid foundation to build anything on, then how come everything is built on top of it? It's the language powering the whole web, and people went really really far with it. Besides that, almost every major programming language can now run in the browser via webassemly, which solves problems in the areas where javascript is lacking raw performace.
Because you have no choice?
Your parent comment already answered that.
You're mistaking "JS is forced on people and they have no choice but to make it work" with "it's everywhere so it must be good".
> how come everything is built on top of it
Can you share something else they could've built everything else on top of, instead? Yeah, that's what I thought.
Do you really think a normal junior dev is going to be/should be writing web assembly code to build a basic portfolio website?
> how come everything is built on top of it
Everything is not built on top of it.
> It's the language powering the whole web
It’s also not powering the whole web, just a significant part of the client frontend inside browsers.
What? No, absolutely not. Did you not learn your lesson when google decided to actively try to kill ad blocking? Why on EARTH would I want all of my desktop apps at the mercy of google and chromium?
You can tell me until you're blue in the face that you also think these apps should be cross-browser but we all know that will never happen.
This is whataboutism. There is still firefox as possible second engine impl and you are arguing its better to not have a layer at all than accepting the possibility google might take it away. Plus most people are on macs or windows where there are at least as bad actors playing against them.
I rather we bring back Delphi and VB6 which if you dim’d your types could run faster than most people realize.
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.
> Electron's value prop
"Now you can have the cross-platform compatibility of a single-page application just by bundling Chrome."
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.
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"?
The problem is that it made everyone's life worse.
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'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.
Would you really need 500mb for accessibility? Can't text to speech be outsourced to the OS or companion app?
And Windows apps had accessibility before computers had 25MB RAM in total. Accessibility is not the cause of bloat.
do any of these native GUI libraries provide just as rich accessibility experiences to disabled people?
If we mean native as in OS-specific GUI APIs built-in to the operating system, then yes. All of the browsers are abstractions on top of that. If we mean cross-platform GUI libraries for Rust I think your choices are like Dioxus (a webview), Tauri (also a webview), Slint (draws its own widgets), and maybe Fltk (draws its own widgets) with extensions?
Yes, yes they do. WXDragon for Rust, for example, provides quite good accessibility. And maybe accessibility would be better for frameworks like QT or DearImGUI if (1) people didn't act like the web was some paragon of accessibility (hint: it really, really isn't, not when websites misuse web APIs -- which happens quite frequently) and (2) UI framework developers didn't just make a UI framework that looked sexy but left accessibility on the floor.
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.
The article implies that a11y will exist on launch and maybe already is.
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.
This is mostly because websites have gotten heavier and we want them to run faster.
How much of that is due to chrome, and how much is because say Jira and YouTube are incredibly bloated?
All the native APIs across major platforms have accessibility features, how do you think browsers implement theirs?
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
Already done. Windows scales dialog resources according to font size, gtk has text only scaling.
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.
By dialog resource I mean this: https://learn.microsoft.com/en-us/windows/win32/menurc/dialo... it's a DSL (analog of glade) that describes buttons, text boxes and their positions in a window, measured in dialog units, these dialog units are computed from the font size per dialog.
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.
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.
Noone is claiming that, though.
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.
Discord actually launched as a web app, and then moved to adding a desktop app, which has quite obviously become far more popular than visiting discordapp.com and using it in the browser.
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!
> 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.
Do you have an employer?
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.
It was never a good solution and there is no reason to ever stop calling a turd a turd.
We could, if people would stop doing it today.
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.
It was only a solution to Web developers that refused to learn anything else.
> 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.
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.
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>.
Probably because it's not meant to be like Bootstrap.js where everyone's UI looks identical?
Even still, some screenshots of here's something we made earlier are always nice to see what's possible
Even imgui has screnshots.
gpui is meant to be a fairly low level library. If you want screenshots check out zed, but be aware that for many use cases you'll have to roll your own widgets.
gpui-kit (formerly gpui-component) provides a richer set of widgets and a Javascript shell. Screenshots can be found here:
https://github.com/longbridge/gpui-kit/discussions/989
I don't know about you but I _want_ all UIs to look identical - specifically I want them to look like they belong on the platform I use, not the fever dream of some product person.
Click either of the 2 links at the top right of the page, and you get screenshots of GPUI apps.
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 :)
https://twitter.com/radgendervibes/status/211810701651020193...
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.
I love when folks complain about C++ in stuff like Qt, and then write C++ addons on Electron apps, to make them actually get an usable performance.
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?
It comes down to package distribution.
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.
Qt is easily obtainable via vcpkg or conan.
Was that true in 2012?
Very yes.
Depends, it was easily obtainable via OS package managers, and installers in 2016.
However that has been true since 2016, and here we are, 10 years later.
For Linux, but not for Windows and Mac
I mentioned "and installers" for a reason, I know Qt since KDE exists.
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.
you can do that easily on linux too
IIRC Qt is LQPL, so if you linked it statically you'd have to license your code as LGPL too. Shipping Qt as a separate dll didn't trigger that issue.
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.
I much prefer vscode to intellij
Why is it no one ever seems to do it then? I have never seen a Java app look or act native on Windows.
Eclipse
I haven't used Eclipse in a decade, so maybe it's changed, but back then it was very much a Java UI, not a native feeling one.
I remember the Java UI, but at some point they switched to a version of Swing that made it look more native, at least on Linux.
Eclipse uses SWT which uses real native controls.
Of course Linux doesn't have native controls - I think it uses GTK on Linux.
It used SWT, which was a thin wrapper over native controls.
Ahh yes that's right.
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.
[1] https://www.formdev.com/flatlaf/
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.
Usually it is hard for those coming from scripting languages.
Strangely enough we managed to write portable code across platforms during the last century, and there were more than only three major desktop OSes.
> 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.
[0]: https://xiph.org/ao/
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
Probably an economical thing. If you have a much higher effort with packaging and testing vs coding the app logic.
If developers don't want to be replaced by AI they need to bring something to the table because employment is not a charity.
Discord ships plenty of native code, though. Actually most popular Electron apps do
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.
The article says they can use the Rust code with wasm as the iOS app and that includes iPad and Android. And Mint is just Linux so it should run fine, just like Zed.
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.
> People love HTML/CSS/JS for very good reasons, and have been willing to accept the resulting tradeoffs.
Developers do. Accountants do. Users just have a bunch of janky apps that don't work right without knowing why, and have no choice in the matter.
> This article does nothing to address that.
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.
You know how much overhead testing 5 different apps still is?! (iOS, MacOS, Android, Windows, Linux)
Users will test.
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?
Oh, does rust have a good native cross platform ui framework?
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.
I hardly see your points on why we shouldn't have cross platform UI.
>>you're going to need a few more people because you have to have someone who understands each platform.
a big no here.
You don't need "native" part if you are moving from Electron app
>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.
Googling if it was a common complaint around launch time shows plenty of threads on it across all the usual sites at that time.
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 was not "bad default settings", like often with UE5, it was "MS did a superb job making VSCode not dog slow like Atom" and it took really lots of work
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
Combine a properly tuned config with a sufficiently smart compiler, and Electron is blazing fast!
Even vs code is slow compared to a native app - noticable with large or many files; with search and replace in larger files (xx mb) it even crashes
I definitely remember it being yet another slow editor many people complained about.
Eh, including a whole browser has always been my complaint and I'm sure many others.
> 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?
> Electron's value prop has always been about having one team producing one app that is supported on multiple platforms with minimal additional effort.
Which is an assumption that made sense pre-2026. It no longer makes sense anymore. Since you can produce multiple apps, one per platform, with minimal additional effort now.
I have only ever worked as a software engineer in mega corps, so my perspective is understandably limited. The value prop that I have observed with Electron is that average JavaScript/TypeScript programmers are cheaper than average Java and C++ programmers. As a result, it can be cheaper to build and maintain JavaScript/TypeScript apps on Electron. To be clear, for years before Electron arrived, it had already been possible to write internal, cross-platform corporate apps using Java (Swing) and C++ (Qt). Also, senior technical management was happy to add RAM to desktop PCs to deal with higher memory requirements for Electron apps. Since the RAM apocalypse, maybe this cost savings has been offset. Still, most corporate desktops are way overpowered (RAM/CPU/GPU) for what normie users need.
I don't understand the hate on Electron. I think most people here never shipped cross plattform apps ever and even less maintained them across cross platform. It's a financial decision. Electron (in the age before AI) enabled to stand on the shoulders of giants to build a reliable product with one code-base among many OSes. Something which Java promised Electron really delivered for most end-user apps. Google poured billions into making the fundament of Electron fast and reliable and bugfree. And it enabled many Linux ports of apps which would have otherwise not happened.
Best example is vscode.
Are Electron apps more wasteful than native: sure. But I rather stand with Electron and that Windows, Mac and Linux is supported.
Sort of, you're right that it's zero sum.
But electron applications that are forced by the first party (IE; third party clients are explicitly forbidden and will be an EULA violation- possibly resulting in expulsion from the platform) is an issue.
We talk about a global RAM crisis now due to AI, but I don't even want to think about how much RAM is hoarded by Teams/Slack and Discord in aggregate- these are applications that are intended to be run in the background by everybody, so you're talking at least 2GiB per person because you can be pretty sure that people are running more than one of these.
1.5GiB * the number of people in work = what.. 150 petabytes of RAM in Europe alone? For chat.
Is that really electron's fault though?
Compare vscode memory + cpu usage to whatever IDE you were using before that. It's probably an order of magnitude more efficient.
VS code is not an IDE, its more similar to Sublime.
In comparison to Sublime, it is indeed slower and more resource inefficient- however, it is free and good enough.
Not everything boils down to technical purity, there can be other important factors.
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.
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.
I volunteer as the arbiter of decency!
VS Code is a perfectly fine and pretty performant app.
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.
I don't know your Standards, but VS Code feels very smooth.
Downvoted without reply, I like that. Give me your arguments or stfu
Based on the hype I tried zed thinking it would feel amazing compared to vscode, and it just didn't.
What do you consider bloated on a VSCode install without any extensions?
Erich Gamma started VS Code (through Monaco). That's saying a lot about Erich Gamma and not a lot about Electron.
It's also had a ton of work done to make it performant. (Microsoft level resources)
Isn't Gamma one of the GoF guys who pushed bloated Design Patterns, UML & co? I would never expect him to write performant code.
Also, first time I'm hearing about Monaco. I thought VSCode was an Atom fork.
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.
VSCode is absolutely not a rich IDE. It's a fancy text editor will extra plugins. Visual studio or IDEA are rich IDEs.
With extensions it can be. And if it would be built on a custom GUI framework, it could not.
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.
Codeblocks is an IDE. VSCode is pretty much on par in terms of features.
It's a spectrum. I'd give codeblocks 25% of an IDE ;) But it will depend heavily on what you expect.
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.
lmfao no.
Just compare Sidex (VS Code clone in Rust) vs vanilla VS Code.
https://github.com/Sidenai/sidex
You mean the app built by a trillion dollar company with a dedicated team spending untold millions of hours making it work?
Wrong, it only performs half way decently thanks to the amount of C++ and Rust extensions it makes use of.
I keep hearing this, but I never see any evidence for it.
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.
Missing the extensions that are required to make a bare bones VSCode actually usable.
Also the performance improvements on the bultin terminal thanks to using WebGL as if it was a native app.
People need to understand even a 70% smaller 290MB GUI app is still terrible. We could open 200 browser tabs on Windows 2000 with only 256MB memory back in the days. Discord should not consume more data than 200 browser tabs.
this is true, I even remember one of the first alternative clients for Discord (Ripcord IIRC) was orders of magnitude more performant and lightweight that this rust rewrite.
200 tabs of HTML only?
Came here to say the same thing. A graphical IRC client should not require 290MB of RAM to run.
if it has a lot of iamges and videos, maybe? but not after a clean startup
You actually couldn't, because browsers did not support tabs back then.
200 browsers instances more likely.
I'm pretty sure my Pentium 3 PC back in the day had 128 or 256MB memory, and I ran tabbed Mozilla/Seamonkey as well as the first versions of Firefox ("Phoenix"), both with tabs. 2003ish.
Cold Phoenix start on Windows XP was similar to Firefox startup today on a Mac :D (ok, maybe a few seconds longer of pegging the CPU)
Windows XP was the follow up to Windows 2000.
Yeah, and it took up to 2006 for IE to support tabs.
Anyway, by then Windows 2000 already had its replacements on Windows XP, and Windows Server 2003.
Opera definitely had them around that time
https://pspb.chrisrcook.com/2025/09/20/4_windows-xp-home-x86...
On Windows XP.
Opera supported win 2000 until 2010s. Same for Firefox which had tabs in its version 1.0 in 2004.
Might be, however the comment I replied to implied any browser on Windows 2000.
https://allthatiswrong.wordpress.com/2011/01/14/opera-did-no...
And? I never said Opera invented tabs (I knew they didn't).
And it wasn't on Windows 2000 heyday.
Opera and Firefox, "actually" (along with some lesser-known browsers), introduced tabs around the same time as, or very soon after, the launch of Windows 2000.
Alternatively, read "tabs" as "windows" - we know the word "tabs" is not the important point of that post (and that the number 200 is exaggerating for effect). Right clicking a link and selecting "open in new window" opened a new window in the same browser instance, not a separate instance, although there wouldn't be any visual difference.
Windows XP and Windows Server 2003 were the current versions at the time.
> People need to understand even a 70% smaller 290MB GUI app is still terrible
I don't understand that kind of reasoning.
Electron - and anything web - has allowed us to basically solve distribution and iterate at lightning speeds and people are getting bothered because an application in 2026 takes multiple amounts of RAM than the their favourite 90s app?
Come now, the average laptop has a ton of memory and fast i/o to be able to not care even if that 290MB was 1290MB.
The trade off of higher memory for some middleware is totally worth it.
Software developers need to realize that their app is not the only one that will be running on the user's computer. A single app taking 300 MB of RAM? No problem. 20 apps? That's already 6 GB of RAM.
And keep in mind we're talking about a damn chat client, not some complex video editing or CAD app.
> Software developers need to realize that their app is not the only one that will be running on the user's computer
The user will need to realize that, and if they don't like it they will close the app and move to a different provider. But that of course will not happen because no matter how the IT people want everyone else to use their xmpp xfce clients or whatever; Slack will always triumph because it is not just a "damn chat client"
> 20 apps? That's already 6 GB of RAM.
No one runs 20 apps in the foreground, my finance runs gsheets, xero and the erp all of which are webkit. The lenovo's were the cheapest ones I could get with 8gb ddr4 and still no one has complained about slack or our erp written in react not being responsive enough.
I understand that people like to constrain themselves for creative reasons but lets not be cheap with resources.
Do you honestly consider this normal? In the 00s I've used to run Windows XP (which was derided as an absolute pig -- what the hell did we know) + Delphi with a GUI designer in it much more advanced than anything we have now + 1-2 PDFs + a web browser with maybe 5-10 tabs + often a chat client in the background (usually QIP -- it supported not just one protocol like Slack, but about a dozen of them, and could send and show multimedia messages in addition to text).
Sometimes also a music player. All of this relatively comfortably fit in 128 MiB of RAM; it was really comfortable once I moved to 512 a few years later, and I thought that should be enough for the decades ahead.
But then we got electron and turning the web into an operating system on top of an operating system.
Now having a document processor barely fit within 8 GiB is considered acceptable...
Normal or not that's how it is. The incentives are not there and the network effects close the casket...
Is it regrettable? Idk. Definitely not unique to software though once you look and appliances, cars etc - they are not optimized for the things I prefer they would have been.
Wish it only took 300mb. Actually that is the minimum.
Teams is a nice example. It will eat 1-2gb of my memory on a regular day. Being limited by 16gb and trying to work... It's not fun.
I recently installed "dvdisaster" from Debian. The provided version has the GUI disabled, on the grounds that it's written in GTK2. It's just a single-line configuration change, so I recompiled with the GUI enabled.
It's been a long time since I last used GTK2. I was shocked at how much faster it feels than GTK3/GTK4 apps. Load time is almost instant on my old computer, and no perceptible latency anywhere. There's no arbitrary 60fps frame rate cap like with more recent GTK versions (while running on Xorg). There are no annoying animations. GTK2 was already perfect and everything since then has been a downgrade.
Congrats, you finally made it 15 years late to the "Gnome 3 sucks" party, you can still grab a drink and a chair, it's still lively in there!
Linux Mint ftw
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?
IMO Rust is great for creating a shared library that native clients then use. Mozilla even made a great library to handle all the FFI bindings:
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.
"the nice language aesthetics" is shit in your head. i want good program without buying additional RAM.
Kotlin multiplatform is horrible on iOS, it’s basically as bad as React Native.
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.
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.
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/...
oof. No proper support for IMEs is a huge non-starter for East Asia. Why don't they just use OS standard text renderers like everything before Rust?
Or is Discord planning to implement their own forks of existing IMEs into the app? Don't tell me they are going to just put in a tiny LLM and call it a day...
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.
What worries me is that there's a general atmosphere that LLMs solved all NLP tasks, despite they don't do so well for kanji pronunciation <-> text mappings, likely for the lack of data - Japanese users especially don't post enough of organic data useful for that, apparently. Discord may be in a "good" spot to be able to (very invasively) collect that data by setting up a keylogger and comparing that to the final user-submitted text, but (aside from all the concerns) I'm not very hopeful about it.
I don't understand this idiocracy - it's super easy (I did myself alone many times) to have a single codebase in Qt for all OSes, even BSDs.
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.
This is definitely true. It seems to be the modern approach that the less effort in development, the better!
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.
Not a front end developer but I’ve always assumed it was ROI - nobody felt a smaller memory footprint would drive enough incremental revenue to offset the costs, compared to the other things they could be doing.
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.
> single codebase in Qt
Not if your promary UI is web.
Qt runs on web too.
Web version has 0 accessibility, which is a no-go for real products
Is it? Discord seems fairly real to me.
Web discord is written in Qt??
> it's super easy (I did myself alone many times) to have a single codebase in Qt
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.
Which cross-platform toolkits are more mature than Qt?
Mature was probably not the best word. The modern desktop UI toolkits produce a better UX to me.
Qt feels too locked in to old decisions that were the right choice at the time, but desktops and mobile have changed so much that it always feels like a clash of old and new.
You can make Qt look however you want. The point is that it will give you native UI by default (for the most part and excluding QML)
That native UI will be faster than Electron and most other retained UI toolkits and will be just as capable of creating whatever your subjective view of “modern UI” is.
I'm still waiting for a single Qt-based app on macOS that feels like a macOS app. They look more like some Windows 95-era app wearing the Aqua skin peeled off the carcass of some slightly older-and-definitely-not-current version of macOS.
Don't confuse UI and UX. You can make Qt have the right UI, you can't make it have the right UX.
This is also why electron and other frameworks really devalue MacOS. Back in the day anything not built with Cocoa felt off, there was a difference in usability.
Now we take it for granted, and Mac apps feel as good or bad as everywhere else.
Qt will look like AppKit for the most part minus having exact the widget types as AppKit.
The person who made a Qt app may be designing it based off of cross platform UX but maybe you should follow your own advice and not conflate things.
You can quite easilymake a native UI and UX with Qt. You can also make things feel very non native via AppKit too.
Your argument has very little to do with the toolkit and more to do with the developers choices of what UX they prefer to design.
I'm with zapzupnz here.
I haven't seen what you describe, even if it's theoretically possible. I'd really love to be shown an example.
I'm not saying it can't happen, and in fact, if it existed I wouldn't have noticed (I mean, the point is that you think it's native, so I wouldn't have noticed..) but I can't think of an example and I would love to see one.
For every one C++ programmer, there are 10 JS programmers.
Unfortunately, as now we are stuck with JavaScript in all places.
I would understand if devs preferred to not bundle lots of libraries, so their mobile apps are faster and slimmer.
And yet most Android apps today take 50-100MB bundle size for very simple GUIs and take up lots of RAM and lots of time to load or react to anything.
So maybe we'd be better off with everyone bundling Qt after all.
Qt licensing is terrible for commercial products. You end up with an account manager that changes every year, compliance within your company is a chore. Qt is fine for things that are and always will be open source.
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.
One good reason: extensibility. Pi is extremely malleable in ways that would probably be harder to achieve if it were in, say, Rust.
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.
I guess it depends on the harness, for example: chatgpt.exe right now is 1 GB on my windows machine. peseo.exe is 500 mb. and opencode.exe + bun.exe is 300 mb.
Chatgpt isn't a harness. OpenAI's harness is codex.
Of course it’s a harness. Every LLM chat interface is a harness.
This is why I like Kotlin (or Java). You can get the extensibility of Python/JS at native speeds and full multi-threading, with fast compile speeds. It does use more memory compared to Rust though.
Because it used to cost extraordinarily more money to build for a performance increases almost no one cares about.
chatgpt.exe right now is 1 GB on my windows machine. I have 16 GB and can spare none. So I don't think that nobody cares about such performance increases.
Most don't care or ever notice these things. Hacker News crowd does and always has, but the a non-technical user of a run-of-the-mill desktop app would rather have new features, and maybe some bug fixes, over performance.
Myself? I care. I regularly run a project that needs 6GB for the language server to provide type hints.
> but the a non-technical user of a run-of-the-mill desktop app would rather have new features, and maybe some bug fixes, over performance.
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.
> chatgpt.exe right now is 1 GB on my windows machine. I have 16 GB and can spare none.
These are not the same units, because all modern OSes have compressed swap.
But you’re running it, aren’t you? So from the business perspective, you don’t care enough for it to matter.
One possible reasons is that all of those are compiled languages vs interpreted. It doesn’t sound like much but compiling your code for three plus platforms and distributing binaries adds just enough complexity and friction to make it feel a lot more difficult.
I agree with that yes but consider how many people would benefit. And how easy it should be for them to do the change (and compile). It's just tokens.
But "friction" is the job, and "complexity" is the job. That's why we're developers.
Modern CI systems have no problem building for 15 or 20 different platforms is what you need. There's a little bit of hassle of distributing binaries but again it's not a big deal for anyone who actually puts their mind to it.
definitely dont mention setting up apple certificates/ code signing.
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.
Because the (wall clock) execution speed / performance oft the harness is tiny compared to waiting for the LLM response.
Because there are more JS programmers, and they need to eat too.
Personally with LLMs now, I don't actually see a reason for dynamic languages at all. LLM now makes it faster so python, js and similar are fully redundant. It's all just inertia for now
Every time I start the discord app, it downloads updates. It was never the case when I opened discord app and it didn't start updating. Updating 7/13. Updating 1/4. There is always some update pushed, I think almost every day. Comparing the launch times of fully updated clients is kinda useless, as it will always take few minutes to update anyway when you are cold-starting it. Slow electron apps are just a skill issue. Yes it has a browser overhead, and it will use a bit more RAM, but the bare-minimum time required to spin up the underlying Chromium shell and Nodejs runtime environment is 100-300ms, everything on top of it is just application overhead aka skill issue. My slack client opens almost instantly all the time, and it's as responsive as any native application around, sometimes even greatly more responsive than some native apps made by Apple.
Not disagreeing with your general comment, but on my M3 Pro Slack takes 15+ seconds to start (usually snappy after that). I fucking hate it.
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/
All modern apps are like this. It's Electron apps which are all legacy.
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.
My point is no Electron app should be considered "modern" at this point.
no true Scotsman
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.
Do you know what tech stack do they use? The website only mentions custom Direct3D renderer.
>Do you know what tech stack do they use?
If you are asking this kind of question you have already lost the plot. You don't need a "tech stack".
I'll pass on paid / proprietary task managers. But cool anecdote?
Isn't that same as passing on all paid software?
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.
Well, why not just move on from Windows and transition to Linux, as I did with CachyOS earlier few days ago. Doesn't even want to look back on Windows now since everything is so smooth and uses half the memory I needed compared to the equivalent in Windows! The only quirk I have is the xe driver that after suspension and resume the GPU may go haywire and I have to restart SDDM but I switched from S3 to S2 sleep and the problem seems to be worked around. I'm using an Arc Pro B50 so not sure if that's buggy on Linux whatsoever but it is metric tons better in Windows.
So what exactly does any of that have to do with switching ann application off of Electron, aside from Windows being in the headlines which makes sense given the site is “windowslatest.com”?
i believe that primary issue of electron is also that the framework consumes RAM/resources which is already a issue especially for windows which is a heavy OS on the RAM. the same side is visible on the Linux speciapic app ends of applications like VS code. they have poor integration , Loads of resource consumption and minimal polish
I really dont understand why when AI is available, big company still using electron for their apps. Codex was written in pure swift on macOS and right now moved to Electron again
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.
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.
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.
> 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.
Why assume finite token budgets? Scaling 2x tokens isn’t a major jump if it brings quality.
Also the GPUI approach is still finite tokens, just better stack.
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.
Users are not the target audience. Salesmen are.
2x a finite value is still a finite value
Electron / react native are dead. LLMs can do the porting over multiple platforms.
Just spend the tokens, the native app user experience improvements are worth the effort.
for a team that was using the underlying stack (other than the ui library) for other components, trying this is a low-hanging fruit of an experiment. this should not automatically become the recommendation for everybody. (yes i do hate electron apps)
for a large project like electron, it is up to the maintainers to optimize it while preserving the api. if they can do this with typescript, they can also explore this with electron. perhaps a native webview option instead of chromium?
with current memory crisis, devs with cushy performant laptops bought over a year ago should realize that we yet again have hardware constraints and need to act accordingly. however, putting the pressure at the wrong place is not as productive.
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.
> 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
QtQuick is quite good.
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.
Name one feature that is a reason for a GUI framework to require lots of resources.
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.
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.
Are you a web dev?
I use ImGui regularly, if you believe that it is on the same level as what you can do with React/HTML/CSS/etc. then I don't know what to tell you
I have seen this assumption in recent GUI threads here (More so your upper post): Building a PC application is not equivalent to building a web browser. A web browser is a type of PC application built for a specific (But very broad!) use. I didn't think I would need to write this statement/distinction, but I have here. Web languages, culture, and syntax have not been a value add to PC application development. Electron is the clearest example why. My model is that is the value add of Electron: Appealing to web devs through language and culture.
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.
it's not just about "appealing to web devs"
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 think anyone likes the look of Qt more than what you can achieve with webapps in terms of UI
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.
> 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)
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.
Listen! The fact is, JavaScript/HTML/CSS are a holy cow, and the Web is a religion. And you will come up with any excuse just to protect your holy temple.
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.
or Rust with things other than GPUI
Crux, lets you use native UI but Rust for business layer: https://github.com/redbadger/crux
On Windows youd use windows-rs
What are they using for the new web app? Is it just plain React now? How is the logic being transpiled to WebAssembly?
What I don't get is why most background electron/CEF applications don't unload the web engine when it's minimized to tray for some time. Chrome starts in about a second, the the webview shouldn't take more than that to re-initialize.
Probably because they have stuff to do in the background and so have to keep the javascript running.
You don't need the whole browser frontend for that though, Electron also includes Node.js which is much less memory hungry.
> Chrome starts in about a second,
on which machine ? go check the first three PCs here: https://www.amazon.ca/Best-Sellers-Laptop-Computers/zgbs/ele... ; do you think they open chrome in a second ?
What would happen if you do not have enough memory to reopen it? How would that impact the user experience?
well that'll probably happen less often if all these electron apps stop using 4GB of ram in the background constantly
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.
Many other Electron apps also have a web version. I just make them pinned tabs in my Firefox.
If you ever wondered about the reasons people started using Telegram, this is a big part of why.
Is that a whole UI re-write in a native/non-web framework? Because in case that's not, this is still running in a browser, i.e. it stands at 80% or so of the bloat factor of electron, and what makes it faster is possibly (mainly?) that they haven't gotten yet to adding as much stuff as seen on the regular client.
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.
Would love to see VS Code ditch Electron
They should ship a native Windows IDE
... oh wait
Theres a small subset of apps where I still think electron can sort of be worth it, but its definitely never any of the always active or second monitor apps like we often end up seeing. I think an app you dont mind closing when youre done, and that doesnt expect or require to be run alongside other demandind apps, could potentially be worth building with Electron. But that is sadly not the category of apps that are often built with it.
I’ve been building an app with Avalonia and it seems pretty snappy. Wonder why it’s not in the comparison.
I hope it's a tremendous success that inspires every app to rebuild native. We've been in the dark ages of desktop apps with 200ms click response times and 15hz rendering, 30 second load times despite having a super computer worth of hardware on every desktop.
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!
I think the reason why web technologies that are essentially being ported to desktop is not only because they provide cross-platform compatibility (still lacking a standardization on Linux), but they tremendously helped the hustle culture built around the motto of "ship it fast" by providing the fastest iterations and benefiting from already existing cheap pool of web developers, especially via outsourcing/offshoring.
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.
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?
Tauri's value prop over EGUI and GPUI is that its syntax is familiar to web devs.
Are there any fully fledged ui frameworks (components) for Taurus that I can look into?
was wondering the same thing; my hunch-memory is that Tauri is not as performant on Windows. but that has not been my experience, Tauri seems great
The argument against Tauri is that it uses system web view so you get platform incompatibilities.
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 also noticed that the "smoothness", when everything feels quicker, is immediately noticeable on desktop (vs laptop), all apps, several laptops (Mac, Thinkpad, Framework).
I find it surprising that they are still investing in performance improvements, because to me for a while now it looked like discord has entered the enshitification stage of life, where they go purely for maximizing profits with no regard for user experience. As they had recently hit the news with their age verification requirements I thought that it's over for discord as they will start limiting the users and selling their data en masse.
You can thank legislators across the globe for the age check thing
That's a skewed perspective.
Discord always deeply cared about their users. Which is why nobody is able to get even close to replacing them.
They are adding user requested features and improvements all the time. They might not be what you consider "improvement", but maybe you are not really their target market.
I literally just run another browser Window with discord on the web rather than the native app.
Discord is probably my least favorite thing to happen to chatting online, but for some reason it's what everyone wants to fucking use.
Discord is my favorite thing to happen to chatting online. It combined everything useful from IRC, Skype and TeamSpeak, in one application and with modern UI, and things we now take for granted like attachments and link embeds. And even 10 years later, there are still no alternatives that aren't just discord but worse.
Discord tab also uses 500-600MB of RAM. This is private resident bytes of the tab excluding browser and its helper processes.
Has this released yet? We're just going from self reported improvement right now?
This gave me a good laugh. Like, who could have known?
There's absolutely no reason why a simple chat client should take more than a fraction of a second to start. If you need to fetch data from the web, just do it progressively. Not to mention that 290 MB is still way too much.
It's ridiculous how over the last 20 years simple apps became slower and slower while computers became faster and faster.
At the same time, REAPER (a full digital audio workstation) opens in less than a second.
These so-called software engineers seem to have completely lost the baseline of what is possible on modern computers. Or they just don't care.
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?
JSON and API's/libraries.
If LLMs are truly driving the cost of "writing code" down to zero, then we shouldn't need Electron anymore. The whining from developers about how it's soooooo hard to write and maintain N separate native applications is no longer valid. Point an LLM at your existing Electron code base and have it fork off a bunch of native ports of it. LLMs are surprisingly good at matching the functionality of existing software. Keep and maintain the Electron app as an internal reference design (your developers probably only know JavaScript anyway) and "build" all your actual production releases from that.
One thing Electron has over Tauri for Discords case is WebRTC. I tried making an open source alternative using Tauri and got plenty far, then I learned that WebRTC on Linux is not OOTB since its still experimental. Webkit on Linux requires WebkitGTK, so everything under the sun out there that had “webviews” cross-platform cannot do WebRTC ootb.
At least now Discord will consume your GPU vram while you game.
This is so close to being fixed!
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.
I think I wound up hacking something in Rust which is less than ideal felt hackish, at that point I was better off just remaking the UI in an actual native UI stack.
Still too many Rust UI stacks are GPU driven.
Signal is still dragging Electron, can't have a working FreeBSD port due to dependency hell. Also VSCode.
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.
Lapce works, so does the ArtCraft suite even on Aros. No Vulkan there, just MESA 26 with OpenGL 4.6+ and that's it.
Altough I use evcode myself. But there are tons of GUI IDE's/editors for Rust out there.
Also, this curb-stoms VS Code:
https://github.com/Sidenai/sidex
that's crazy didn't even know sidex existed, I'm gonna try it later
You can install Lavapipe to get a software rendered Vulkan driver, it's not as fast as a GPU but pretty reliable. It even works on Windows.
Lite XL is fast.
Just use the website. It's going to be a better experience than the vibecoded Rust approximation for the foreseeable future
For me the ugliest part of Electron is that it uses client-server model inside a program and includes both a browser and Node.JS. This is so stupid. If you love microservices so much why don't you put every React component in a separate process?
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.
I somehow doubt hr element is the reason Electron is a bloated shitpile.
AI;DR.
"Technology: Role in Discord | Not used" was most useless table in a while, that was when I noticed.
Back in the day, Microsoft got into trouble for shipping a free browser together with its OS (https://xkcd.com/1118/). Somehow I wasn't expecting 'every app ships its own browser' to be the solution.
To be fair, multi-platform GUI development is _hard_ to do properly, just look at the differences between menu bars on Windows and Mac OS. In theory you could ship electron once as a dependency, similar to the various MSVC++ runtimes, but then you've reinvented 'dll hell'.
Any attempts to fix this probably end up with https://xkcd.com/927/
Yeah, native clients are pretty great. Why did you think people kept risking getting banned in order to use them?
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.
WebView2. Other applications can also use it but it seems like there's less out-of-the-box functionality than Electron
By being dishonest and misleading?
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.
By reusing the system webview? It's what web frameworks should've done.
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.
That’s also how Tauri claims to use so little ram.
This website could work much faster if it wasn’t loading 100s of ads.
Low effort article.
Related:
Discord is ditching Electron and its new app uses less RAM
https://news.ycombinator.com/item?id=50378625
Discord just showed how low the bar is, if the new version in considered lean and fast.
On my mac I’ve banned Electron apps, only native ones - Slack on Safari.
I’m disappointed to see the continued proliferation of JavaScript and TypeScript. I cannot fathom why people are using these garbage languages still when we have so much better options and code is essentially free now.
These languages were developed for hypertext. Discord is hypertext. The question is why Rust or C++ or anything would be so suitable for developing chat rooms; it’s not even clear why JavaScript would necessarily be slower after being statically compiled.
It’s not just about speed. Have you ever come across the utter tire fire that is npm? Or the horrors of [object Object]?
Yes, the first one is not required and shouldn’t be used, write your own leftpad then. The second is about as awful as getting NaN, which is to say not, and can be overridden in the prototype anyway if you want more casual logging.
So Discord rediscovered that native apps are faster? Until fairly recently, every proper desktop "app" was written in C/C++. In other news, water is wet.
Agreed, Electron is garbage.
Hot take, but: love electron. Write once, runs anywhere. The majority of bugs aren't platform specific. Easy to get nice visuals that stay consistent across different OS. Yes, it's not native. I don't care. It's not a painting to be admired. The focus on looks and visuals versus usability and ux is a plague.
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.
> Yeah, it takes some extra ram. Fork my stuff and rewrite it in rust if you care. I don't.
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.
If it's FOSS, what's your beef? You want a native version, point a clanker at the repo and tell it to party on.
It's the other way around though. A lot of times, it's spending system resources so that they can use something that will run on your OS. Most apps using electron wouldn't have linux versions if electron wasn't a thing.
That doesn't mean you can't use something better when that comes along. Using these new Rust GUI frameworks is basically the same as electron, you use rust instead of web tech.
This approach isn't groundbreaking, QT framework does this commercially for the past few decades. AI has just made it easier to manage & migrate.
Crazy what passes for journalism these days.
we should kill web-monkeys.
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.
Great option for this that lets you use Rust along with real native UI for cross platform: https://github.com/redbadger/crux
"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.
https://github.com/redbadger/crux/tree/master/examples/count...
Rust to death i told them
Many people dislike Electron, but there's a reason it's still widely chosen. It runs on Linux, macOS, and Windows. With C++ or C#, you have to build differently each time, and cross-platform support is difficult. And fundamentally, it brings over web syntax as-is more than other frameworks, making front-end styling convenient.
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.
> 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.
because native apps aren't slow. Businesses didn't want to spend money on redundant effort replicating the same feature for each platform. No matter how efficiently you use electron, it is fundamentally a browser and server in a strait jacket pretending to be app. That's why it's bloated/inefficient. The JS framework used in negligible in comparison.
Not as efficient as native, sure. But have you actually tested it?
If browsers were inherently slow why do plain HTML+CSS pages (no JS) run nicely? Then consider the fact that modern JS runtimes are competitive with ART (native Java/Kotlin apps on Android). Where is the main source of inefficiency?
Browsers are just another runtime - you can write inefficient code in anything, even native.
> 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'm not directing this at you, but to all developers using Electron and its ilk:
Show some empathy for your users and shoulder that cognitive load so that your users can have their hardware back. That's just courtesy, and a responsibility a good engineer takes on. There are so many more users than there are of you, their aggregate gain from your efficient software far outweighs whatever extra work is necessary to do the decent thing.
I don't think you're wrong. But there's a limit to the languages and technologies a person can learn. In that sense, Electron is efficient. Just as a product doesn't necessarily win just because it has better performance.
So, it has always been a skill issue.
OR you can use Lazarus pascal and ship a 5mb application that uses 13Mb of RAM and runs everywhere instead of a 150MB installer that installs the nth multigb copy of the same application with different hat that leaves free 13Mb of RAM. https://github.com/alainnothere/mailBoy
Electron apps are a disease.
BUT BUT THEY LOOK GREAT, LOOKING GREAT SHOULD COST 1000$ OF RAM BUGA BUGA...
Could they of used servo?
I would not add alternative accounts to the account switcher, they've used these to coordinate bans ever since the account switcher's inception.
interesting, I would have guess Tauri. til GPUI
Don't worry I'm sure they'll find a way to make the rust based client crawl too soon enough.
Slapping a few million lines of AI generated slop code ought to do it for instance.
I've not seen the performance deficits demonstrated in this article. The article also does not discuss the specs.
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.
I think this article is misleading, you can use any framework to make slow bloated software. A great thing about Electron and similar projects is that you get one codebase which is useable on many different platforms. An Electron application can easily be a website and PWA, then the user can choose what they prefer.
A good example fast / "performant" software which uses Electron is Obsidian.
Yes Electron isn't perfect, but I think it's a good choice for many situations. Same for Tauri, CapacitorJS, etc. Regardless of which is chosen, there should be an effort to make software performant and non-bloated.