Every Windows 11 app should kill Electron, and Discord just showed why
windowslatest.com
windowslatest.com
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.)
I think it'll be fixed soon but it drives me nuts.
Flutter is under appreciated for desktop.
https://github.com/DioxusLabs/dioxus#experimental-native-ren...
Blitz itself is a great experiment in debloating.
see also https://github.com/pathscale/izumo
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.
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.
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.
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.
And more memory usage can slow down the whole system, because the system may need to swap and compress memory.
I think that's also the main reason software like VS Code is electron based and not browser based.
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.
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".
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?
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.
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.
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.
"Now you can have the cross-platform compatibility of a single-page application just by bundling Chrome."
Not a great justification, but it made a bit more sense then.
The solution is to use user interface toolkits that are available on each platform. For example, wxWidgets or Qt or appropriate bindings to them if you can't be bothered to write UI code for each platform you're targeting.
Why not? Microsoft released IE for win16, win32, wince, macos system 7 through 9, macos X, Solaris, HP-UX. If it ran on all those platforms, Microsoft probably could have supported it on any platform that had the capability of running graphical web browsers.
I don't see how reusing web code is an advantage. Web code is for the web. We are talking about a native platform (Windows 11) which has a mature API platform stretching back decades. Why would you need to make it "web"?
For a long time, and mostly out of frustration, I wanted to build my own stack of software around my vision. But the mammoth amount of effort it would require meant I never went through with it.
Google Chrome generally used around 25mb per tab in 2010. Today, that number is often 500mb or even 1gb.
What's oddly being ignored in this entire thread (so far, as of the time of writing) is that back in 2017-2018 Discord was an Electron app and was completely inaccessible. The web did not magically bring accessibility to the table -- we disabled people had to go yell at Discord to fix their shit, and even then it took them like 2-3 years, and even now Discord has some very very weird accessibility issues that will randomly crop up here and there.
And it doesn't require that huge amount of RAM, no. What requires the Chrome RAM is running JavaScript and do it fast, and a lot of extremely complicated features, most of which a single app will never use.
1. Use the make everything bigger/font size settings to change the size of what I currently can't see
2. Restart
3. Open every application I need, and go through every major feature in each of them to determine if I can still see things comfortably, while making sure no elements have exploded in size as this also leads to usability problems
4. If not, go to 1
I have to do this every time I install a new application, or one of them updates and changes their UI or decides to opt into the Windows accessibility settings. The latter one happened a few years ago with Firefox, and cost me a day to sort.
Invariably, it leads me to compromising on what I can and can't see.
Election predates WebAssembly by 5 years and hit the scene only one year after Rust was first created.
And just like JQuery, its time is coming to a close as better frameworks are available now that weren’t available back then.
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.
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 would be lying if we did that. Electron was never, ever a good solution. It was something solely used by devs who prioritized their own ease of work over the actual user experience, i.e. bad devs.
Acting like this is a decision the ICs make is disconnected from why electron is so prevalent.
Someone would have been able to disrupt that market by making a much better chat app since Elecron is so bad for user experience.
Luckily in the modern era we have invented language models, which allow us to expend vast resources on text generation instead.
I dunno if you've been living under an enormous rock, but they used AI to make this.
At the time Electron came out, there weren’t as many cross-platform UI frameworks available that they could have gone with.
You can see this with the comparison chart. GPUI effectively replaced Electron so the desktop app UI works across platforms. React Native is replaced with WebAssembly so that Rust can be the primary language across all platforms including mobile.
It seems like the new situation for Discord is rather elegant, and that none of this would have been available when it first came out.
The first thing anyone would want to know when choosing a GUI framework is how it looks by default. Every major GUI toolkit has screenshots on their websites.
This happens so often it makes me wonder if people just don't know how to take a screenshot and put it in a webpage with <img>.
gpui-kit (formerly gpui-component) provides a richer set of widgets and a Javascript shell. Screenshots can be found here:
> Hi Stanislav, I'm one of the core maintainers for GPUI at Zed, if anyone at discord would like to talk to us about improvements to the framework or to upstream your customizations, please get in touch! My DMs should be open :)
https://twitter.com/radgendervibes/status/211810701651020193...
I'm very excited to see GPUI extended for general purpose usages in the future.
The only way to ship the same code between linux, macOS, and Windows would have been to either use something like Qt or the JVM back in the 2010s. The JVM desktop stuff was super ugly and Java itself had become notorious (also if you wanted anything remotely interesting like webcam/microphone or multimedia access you'd still have to ship dynamic libraries). Qt required special packaging skills to ship to the end user especially if third party libraries were involved. Electron killed that by bundling chrome (and chrome has a huge api surface).
Today, I would argue the package management situation for a language like rust is a lot different. You dont have to cobble different DLLs together, you can just statically compile dependencies and cargo/rust do a pretty good job of making sure it's bundled with your app. Other languages also now have similarly useful tools.
Chrome had already solved the hard problem of "how do we support webcams on linux, windows, and mac" and you as the dev just needed to use the Javascript webcam api. ( https://developer.mozilla.org/en-US/docs/Web/API/MediaDevice... )
In C++ land, you are ultimately going to either need to cook up your own webcam library or look for a 3rd party (which, in 2010, likely didn't exist) to provide it.
Today, there are a few easy to discover rust crates which provide cross platform webcam apis. But further, rust does cross platform better than C/C++ IMO. It's really easy to change how code is compiled based on the target. That was all well thought out because rust was supposed to be a language for browsers.
However that has been true since 2016, and here we are, 10 years later.
People get too hung up on package managers. When you're building your own proprietary you don't really need a package manager, you just need a central place to download the tarballs from. Or you could do a monorepo and just build everything locally - in 2012, that means you start your build before you leave Friday afternoon, and when you come back Monday, everything's built.
The hard part of all webcam libraries is all the different webcams running all their different proprietary protocols.
It's not that difficult to write cross platform C++ code. Consuming the dependency is always painful. What build system does it use? What compilers does it support? How do you get the code? There is 0 standardization for these things.
C++ code isn't always that portable either. Old code in a new compiler is very likely to break on warnings, especially if the old code made the high quality decision to hard code -Werror in their build system.
From personal experience Rust as a package and ecosystem is far more portable than C++.
The only reason why a cross platform well supported C++ package/module isn't available is because nobody has bothered to build it.
If it really is something that bugs you then be the one to do it, throw your clanker of choice at it and integrate it into a project you run in production.
"Chromium ahips with it" isn't a valid excuse these days, that is likely an hour or two away with a modern LLM, building and packaging electron is more work.
The real difference is that Rust provides a package repository with a unified build system that's as simple to use as NPM or NuGet.
vcpkg which is similar exists today, but it didn't in 2015 when Discord started, still isn't anywhere near as comprehensive as package repositories for languages where package management is part of the standard toolchain, and the underlying build systems are far messier under the hood.
It can also be helpful in development to use libraries built from source as part of the application's build process, at least as an easily-accessible option, which wasn't common practice in most C/C++ ecosystems historically where different libraries used different build systems and if you wanted to integrate them into something like a Visual Studio solution for easy reference to source code during development and debugging you were often on your own.
Of course Linux doesn't have native controls - I think it uses GTK on Linux.
Strangely enough we managed to write portable code across platforms during the last century, and there were more than only three major desktop OSes.
Yep, that argument always seems strange too me. Do people fear that much to design their own interface and hook to each platform ecosystem? You look at something like the BSD which runs brought one single kernel concept and various subsystems across a variety of hardware. And somethine like libao[0], which provides a common interface to various sound system.
Whatever the app, if you care enough, you can abstract the core features away from the GUI and other various dependencies.
[0]: https://xiph.org/ao/
How outrageous to demand that a software developer possesses the 'special skills' to ship a Qt application. It's not surprising that people think AI is killing programmers when this is the level the average 'programmer' has been operating at for 15+ years.
Imagine going to a chef and he tells you he can only warm up microwave lasagna because cooking the steak correctly requires special skills. The special skills are your job
That can be done. It can be done well. It's not (or rather never has been) cheap or flexible or agile (in the market, not SWE sense). People love HTML/CSS/JS for very good reasons, and have been willing to accept the resulting tradeoffs.
Maybe that's changing now that you can vibe-port a lot of this stuff. We'll see.
This has been addressed many times now, and the article doesn't really need to re-address it.
Coding LLMs make managing cross-platform native apps significantly easier than it was in the past. The cost-reward analysis, where Electron and simile apps made sense because then you don't need to have an iOS expert, a macOS expert, etc, and having a bloated monstrosity of an app is an acceptable compromise, is simply no longer true.
I know there is some subset of HN that still thinks CoPilot 2024 is the state of the art and will declare this a foolish assertion that good developers like them disbelieve, but this is what all of the industry is moving to.
Certainly, if you write a native UI for every platform, you're going to need a few more people because you have to have someone who understands each platform. However, with a little bit of work you can define some good interfaces to that UI and most of your needs are going to be things that are not the UI framework but they're logic that can be cross-platform.
What cross-platform frameworks give you more than the UI is all the other pieces you need. I've written a bunch of applications in Qt Core with no UI at all because it's so convenient to have those Qt abstractions.
>>you're going to need a few more people because you have to have someone who understands each platform.
a big no here.
That was absolutely not the case at all. At least not on HN or twitter. It was for Chief Complaints for Atom. When VS Code first launched everyone was suggesting how much faster it was compared to Atom. And how a properly tuned Electron Apps could be fast. And Microsoft promised it will get even faster that makes everyone excited.
The only few of us who were complaining was how could everyone judge this to be fast when we have Sublime. And that was even before Sublime had GPU rendering.
I find it odd you see otherwise.
And VS 2026 is faster than VS Code these days, now that they spent time optimizing it.
It used to be fast before 2010, when they used MFC (or something very similar to it, I don't remember anymore), compiled to native code.
>This article does nothing to address that.
Article mentions they chose not to use windows native tech (WinUI), presumably for portability reasons. I have no idea how much work it would take to port the Rust client to other platforms, though. Maybe the same code already builds everywhere?
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.
With the ram prices as crazy as they are. It's pretty frustrating to have to run multiple GB eating applications just to do some basic tasks (90% is read and write messages, in the case of Discord). I understand that other people might use the more advanced features (voice chat, etc) but these could be loaded on-demand.
It's a bit crazy to me that I can comfortable run an entire Linux stack (+ Podman, monitoring, alerting and multiple services) in 512 MB ram (with 40% free, just checked!). However my Windows PC needs 5.5GB just to show the desktop! Realistically it needs somewhere between 8GB and 16GB for some basic web browsing and even then it can feel slow if you have a few apps like Discord running in the background.
You show this by all your other comments on memory. The reason apps take memory is Electron.
Plus I prefer apps that behave like OS native apps not the reduced GUI of web apps.
It's also had a ton of work done to make it performant. (Microsoft level resources)
Also, first time I'm hearing about Monaco. I thought VSCode was an Atom fork.
There's only 0.7% Rust code and not even any C++. And almost all of that Rust code is for the CLI, not the editor.
The rest is just plain TypeScript and other web technologies.
Also the performance improvements on the bultin terminal thanks to using WebGL as if it was a native app.
200 browsers instances more likely.
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)
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.
https://pspb.chrisrcook.com/2025/09/20/4_windows-xp-home-x86...
https://allthatiswrong.wordpress.com/2011/01/14/opera-did-no...
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.
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.
And keep in mind we're talking about a damn chat client, not some complex video editing or CAD app.
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.
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...
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.
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.
This bit is obviously subjective, but Rust as a language is simply not ergonomic enough for a lot of the use cases people are trying to apply it to, especially UI development. Most of the Rust UI libraries I've seen to date either use a more imperative style, or attempt to replicate more declarative approaches like Compose UI or SwiftUI, but without the nice language aesthetics that make it simple to read and write. And if the counter-argument there is for LLMs to be reading and writing this stuff, that's a whole other can of worms: (1) The subsidized inference era is quickly coming to an end and (2) if you're using LLMs anyway, why not maintain apps that are as native to each platform as possible?
https://mozilla.github.io/uniffi-rs/latest/
Mobile UIs are different enough and, these days, easy enough to construct that to my mind there isn’t much value in the cross platform UI proposition these days. But logic? Sure.
There was legit a point where I considered embedding a webview just for the QR code scanning screen, but of course, embedding a webview turned out to be a similar mess.
I now have a separate QR scanning implementation for three platforms and a bunch of if statements in the Gradle files. It took 4x as much effort (once for each platform, plus the work to tie it all together) and now I also need to know how to develop for those platforms, which is exactly what I wanted to avoid by picking a cross-platform toolkit.
This will hopefully improve with time, as it did with RN and Flutter, but my point is that we're simply not there yet.
Most Rust GUI toolkits, at least in 2025, did not have that good accessibility or IME: https://www.boringcactus.com/2025/04/13/2025-survey-of-rust-...
Hopefully this has gotten better and the new discord client isn't worse in that regard.
I haven’t tested it or written anything using GPUI, but I’d expect it to be considerably harder work, based on the maturity of the web stack in this area. My assumptions have definitely been proven wrong before though… Anyone from Discord working on accessibility want to chime in?
[2] https://github.com/zed-industries/zed/blob/main/crates/gpui/...
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...
I think people become super lazy... "Ah, it's will ocupie a few hundreds of RAM, no problem, let's ship it."
They are companies with billions or even trillions shipping shit with Electron.
I too had code that worked across 3 platforms with wxwidgets and a 3D game toolkit incorporated in opengl for visualisation, with most 2d controls being drawn using wxwidgets OnPaint handlers for custom controls rendered natively on that platform. I wrote this single-handedly, with another colleague handling the network code and firmware on the remote hardware devices.
Everything else is sheer laziness as far as I am concerned. There's even less excuse today with the rise of LLMs to do the majority of UI coding for you.
What seems to have changed is the size of the costs - LLMs are really good at this - such that you can now say “well, maybe the returns aren’t that big, in fact maybe they’re zero, but this is easy enough, so why not”
De minimus improvement has always suffered this problem - we’re all fairly sure it’s worth something. Maybe there’s even real perceptible value when you fix the whole basket. But making the case is hard.
Not if your promary UI is web.
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.
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.
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.
Don't confuse UI and UX. You can make Qt have the right UI, you can't make it have the right UX.
Now we take it for granted, and Mac apps feel as good or bad as everywhere else.
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 make 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.
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.
Hiwever, I'd like to hijack this front page article to for a related concern/question I've got.
It seems that all (popular) opensource LLM harnesses are either in JS or python (pi, hermes, opencode, paseo). The same seems to be true for closed source harnesses that I have used (deepseek, chatgpt).
I'd really like to ask why? I mean why somebody would use technologies like JS or python to implement a harness application instead of golang or rust or even C? I understand that before 1 year JS or python would be tempting but right now? Especially the LLm related companies have unlimited tokens and re-writing the harness software to golang or rust should be trivial.
This would benefit so many people (especiall considering the prices and scarcity of RAM these days).
So, why nobody does it? This is an honest question, I don't want to offend interpreted languages but it should be a universal truth that a compiled language is faster and consumes less ram.
The resource usage of my harness is nothing compared to an electron app, and being able to easily customize it is more important to me than saving a few extra MB of ram.
Myself? I care. I regularly run a project that needs 6GB for the language server to provide type hints.
Ask anyone with a 5 year or older laptop that wasn't top of the line when it came out and can't afford a new one, and I think you'll find they're of the exact opposite opinion. And even if they aren't explicitly, they might have abandoned their PC and instead switched to their phone for their personal computing, just because that experience turned out more coherently for them.
Heck, even the normal user with a decent laptop probably would take better performance if given the option, but when have they ever been given that option? The current state just isn't unperformant enough that it crosses the threshold to the point where it's at the front of mind for people. If anything, that threshold is probably beyond the threshold of 'eh, I'll just use my phone for this' for any task that doesn't need a keyboard.
These are not the same units, because all modern OSes have compressed swap.
If you are asking this kind of question you have already lost the plot. You don't need a "tech stack".
I don't know...there seems to be something unpleasant about all Electron apps.
I did use VS code for a while but I've just gone back to using QT Creator simply because it is so much faster to use in daily life.
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.
Just spend the tokens, the native app user experience improvements are worth the effort.
Raycast, originally a native macOS launcher, recently released v2 using a hybrid architecture. It’s not Electron, but it follows a similar approach to Spotify’s desktop app, using web technologies inside a native shell.
The memory usage is still pretty significant. It’s using around 350–450 MB at idle and can sometimes reach 1–2 GB depending on the workload. The upside is that they can now share most of their code across macOS and Windows and evolve beyond being just an app launcher.
It’s always been about trade-offs, and LLMs don’t fundamentally change that.
GPUI is one example: some of the downsides of electron (UI is not native), but it solves memory and performance side, and shared codebase.
Just writing native apps because LLMs makes it cheaper is the other option. Shopify did this after years of react native.
The opposite is also true. My argument is that you can also ship Electron apps with more features more quickly with LLMs.
You still have a finite token budget. With native apps, you have to split those tokens across multiple platforms, whereas with Electron, you can reuse most of the code.
Big companies have been going back and forth between native and cross-platform approaches even before LLMs. They generally have the resources (humans, tokens, compute) that small and medium-sized companies don’t have. So I’d take their rationale with a grain of salt.
Also the GPUI approach is still finite tokens, just better stack.
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 ?
Also, pro tip, you can still just use it in browser. I hope that doesn't go away.
it would be absolutely awful
compared to chromium, it's really limited, like it's just always a compromise with these
we should instead figure out a way to do electron but better and make it easier to do the things you can do with e.g. React with native languages and frameworks
If you just reimplement Electron in a native language then you get... Chrome, which is already written in C++. The majority of RAM usage in Electron applications is from the native parts of Chrome itself and a decent ~40 MiB chunk for the Node.js runtime.
To me it seems like all frameworks and apps use much more memory than 10 years ago, but don't really offer more features.
Maybe a really young GPUI still has limitations, but I doubt it would suddenly need to use 5x as much memory if you added them.
edit: Avalonia is quite mature, with accessibility to boot.
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.
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 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.
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.
... oh wait
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!
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.
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 probably my least favorite thing to happen to chatting online, but for some reason it's what everyone wants to fucking use.
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.
In a way, applications regressed a lot with react native and electron. I get it’s easier to develop but the apps are very bloated and underperforming even on computers with 10-100x more power.
At least now Discord will consume your GPU vram while you game.
I am guessing this is just capture/playback code issue? You have a portable WebRTC stack in rust https://github.com/webrtc-rs/webrtc
I haven't used Tauri myself but this sounds like a fun thing to go fix. Silly this is a blocking issue.
Still too many Rust UI stacks are GPU driven.
https://github.com/zed-industries/zed/discussions/17212
I don't know if we have a winner here.
Altough I use evcode myself. But there are tons of GUI IDE's/editors for Rust out there.
Also, this curb-stoms VS Code:
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.
"Technology: Role in Discord | Not used" was most useless table in a while, that was when I noticed.
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/
Low effort article.
Discord is ditching Electron and its new app uses less RAM
Yeah, it takes some extra ram. Fork my stuff and rewrite it in rust if you care. I don't. The few hot spots can be fixed by using a lower level language. Is vs code not zippy enough? I certainly haven't noticed the slowness. People keep complaining about unnecessary load as if hardware hasn't progressed since 2004. It's hugely important for things like your OS. A few apps you run twice a month? Who cares.
But what about software used by billions, asks a person angry about my electron project used by thousands? How many ages were taken up by the five second startup time when you multiply that by however many users (all this time would be spent curing cancer of course)? Sure, improve performance when needed. For the vast majority of projects it's not needed. The average computer isn't pi zero.
And that, right there, is why people hate apps which use Electron. You are spending my system resources so that you can be lazy and not have to program as much. That's not really acceptable development practice.
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.
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.
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 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.
Electron apps are a disease.
BUT BUT THEY LOOK GREAT, LOOKING GREAT SHOULD COST 1000$ OF RAM BUGA BUGA...
Slapping a few million lines of AI generated slop code ought to do it for instance.
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.
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.