"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 increase 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.
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 native parts that aren't available in the web version.
Why do you think that is?
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.
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.
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 it for 15+ years
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.
>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.
This article does nothing to address that.