cheschire
4 days ago
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.
ksec
4 days ago
>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.
rendaw
3 days ago
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).
tcfhgj
3 days ago
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
cowlevel
3 days ago
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"
tancop
3 days ago
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.
p_l
3 days ago
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
troupo
3 days ago
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
groovy2shoes
3 days ago
Combine a properly tuned config with a sufficiently smart compiler, and Electron is blazing fast!
ThunderSizzle
3 days ago
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.
load-bearing
3 days ago
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.
SideQuark
4 days ago
Googling if it was a common complaint around launch time shows plenty of threads on it across all the usual sites at that time.
eddythompson80
3 days ago
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.
fy20
3 days ago
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.
stuaxo
3 days ago
Eh, including a whole browser has always been my complaint and I'm sure many others.
herbst
3 days ago
I definitely remember it being yet another slow editor many people complained about.
user
14 hours ago
accurrent
4 days ago
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.
72deluxe
4 days ago
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?
cogman10
4 days ago
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.
bluGill
4 days ago
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.
MindSpunk
3 days ago
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++.
pjmlp
4 days ago
Qt is easily obtainable via vcpkg or conan.
edoceo
4 days ago
Was that true in 2012?
pjmlp
4 days ago
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.
justincormack
4 days ago
For Linux, but not for Windows and Mac
pjmlp
3 days ago
I mentioned "and installers" for a reason, I know Qt since KDE exists.
Krutonium
4 days ago
Very yes.
bluGill
4 days ago
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.
jpc0
3 days ago
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.
jasomill
4 days ago
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.
vrighter
3 days ago
you can do that easily on linux too
hobo123
3 days ago
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.
cosmotic
4 days ago
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.
threetonesun
4 days ago
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.
deergomoo
3 days ago
I love JetBrains IDEs and have been using them for a decade, but I’d say their general behaviour as user interface is among their worst qualities. Chief of which being how any sort of dialogue or additional window is fully modal. Opening any of the settings windows for example completely locks you out of interacting with the main window.
I find them janky as hell, but their ability to wrangle code is top class.
pjmlp
4 days ago
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.
cosmotic
3 days ago
That look and feel still exists last time I checked. There is also a similar one on windows.
johnny22
3 days ago
I much prefer vscode to intellij
NetMageSCW
4 days ago
Why is it no one ever seems to do it then? I have never seen a Java app look or act native on Windows.
pacoverdi
3 days ago
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.
cosmotic
3 days ago
It takes one line of code to get native look and feel in swing. Not sure why so many didn't do it.
dingaling911
3 days ago
Eclipse
sdthjbvuiiijbb
3 days ago
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.
dingaling911
3 days ago
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.
cowlevel
3 days ago
Eclipse uses SWT which uses real native controls.
Of course Linux doesn't have native controls - I think it uses GTK on Linux.
cyberax
3 days ago
It used SWT, which was a thin wrapper over native controls.
dingaling911
3 days ago
Ahh yes that's right.
cosmotic
3 days ago
Eclipsed used SWT which produced actual native controls. Swing controls are not native but look and feel native.
hobo123
3 days ago
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.
saagarjha
3 days ago
Discord ships plenty of native code, though. Actually most popular Electron apps do
Barrin92
4 days ago
>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
expedition32
3 days ago
If developers don't want to be replaced by AI they need to bring something to the table because employment is not a charity.
hobo123
3 days ago
Probably an economical thing. If you have a much higher effort with packaging and testing vs coding the app logic.
pjmlp
4 days ago
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.
skydhash
4 days ago
> 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/
vivaldi_bt
4 days ago
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.
mrheosuper
2 days ago
Then why not static link library ? And please don't mention about the app size because you are already fine with shipping the entire browser with your app.
asveikau
3 days ago
> 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.
Correction: you didn't know how to do it. That doesn't mean nobody could.
Hence, electron came on the scene and enabled people without that particular experience or skills to create desktop apps.
Grumpier people like me rolled their eyes and said people should just write desktop apps similar to how it was done in the 1990s, to which the answer was generally "that's too much work". If this is changing, I would guess it's because AI is now doing that "too much work" for them.
Grombobulous
4 days ago
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.
jenadine
4 days ago
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.
braiamp
4 days ago
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...
sbarre
4 days ago
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.
thiht
3 days ago
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.
pjmlp
4 days ago
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.
AlienRobot
4 days ago
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>.
rstat1
4 days ago
Click either of the 2 links at the top right of the page, and you get screenshots of GPUI apps.
Grombobulous
4 days ago
Probably because it's not meant to be like Bootstrap.js where everyone's UI looks identical?
small_scombrus
4 days ago
Even still, some screenshots of here's something we made earlier are always nice to see what's possible
jen20
3 days ago
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.
AlienRobot
4 days ago
Even imgui has screnshots.
thisismyanon2
3 days ago
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:
NetMageSCW
4 days ago
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?
Pxtl
4 days ago
Oh, does rust have a good native cross platform ui framework?
bluGill
4 days ago
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.
m00dy
3 days ago
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.
Sankozi
3 days ago
You don't need "native" part if you are moving from Electron app
throwaway2037
3 days ago
> 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.llm_nerd
4 days ago
> 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.
peebeebee
3 days ago
You know how much overhead testing 5 different apps still is?! (iOS, MacOS, Android, Windows, Linux)
GoblinSlayer
3 days ago
Users will test.
RunSet
4 days ago
> Electron's value prop
"Now you can have the cross-platform compatibility of a single-page application just by bundling Chrome."
zdragnar
4 days ago
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.
72deluxe
4 days ago
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.
toast0
4 days ago
> 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.
wiseowise
3 days ago
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.
72deluxe
3 days ago
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"?
IshKebab
4 days ago
> 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.
andai
3 days ago
> 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?
ajross
4 days ago
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.
jen20
3 days ago
> 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.
ajross
3 days ago
> bunch of janky apps that don't work right
Is that really fair? Those janky apps include vscode and slack! There are real technical arguments, but they're comparatively minor and very treatable when you look at it as a technical hurdle.
Which is I think why people who've picked a side get so upset over it and find themselves resorting to vague adjectives like "janky".
jen20
3 days ago
Yes, both are super janky. Slack in particular (I have used it all day every work day since 2014). Random stuff just doesn’t work constantly, and none of the platform conventions are respected. VS Code respects the platform less than JetBrains products, which are also cross-platform.
NetMageSCW
4 days ago
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.
dmix
4 days ago
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.
SOLAR_FIELDS
3 days ago
> 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.
tekla
4 days ago
The problem is that it made everyone's life worse.
johnh-hn
4 days ago
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.
freecodeio
4 days ago
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
hajile
4 days ago
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.
masfuerte
4 days ago
And Windows apps had accessibility before computers had 25MB RAM in total. Accessibility is not the cause of bloat.
freecodeio
4 days ago
do any of these native GUI libraries provide just as rich accessibility experiences to disabled people?
TJSomething
4 days ago
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?
ethin
4 days ago
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.
afdbcreid
4 days ago
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.
saagarjha
3 days ago
This is mostly because websites have gotten heavier and we want them to run faster.
hobo123
3 days ago
How much of that is due to chrome, and how much is because say Jira and YouTube are incredibly bloated?
Ygg2
4 days ago
Would you really need 500mb for accessibility? Can't text to speech be outsourced to the OS or companion app?
pjmlp
4 days ago
All the native APIs across major platforms have accessibility features, how do you think browsers implement theirs?
sitzkrieg
4 days ago
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
GoblinSlayer
3 days ago
Already done. Windows scales dialog resources according to font size, gtk has text only scaling.
johnh-hn
3 days ago
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.
GoblinSlayer
3 days ago
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.
johnh-hn
3 days ago
Ah I understand what you mean now. Thanks for the clarification.
Grombobulous
4 days ago
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.
afdbcreid
4 days ago
We could, if people would stop doing it today.
bigstrat2003
4 days ago
> 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.
rpdillon
4 days ago
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.
Grombobulous
4 days ago
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.
kristiandupont
4 days ago
Do you have an employer?
pjmlp
3 days ago
It was only a solution to Web developers that refused to learn anything else.
qlte
2 days ago
Before Electron/VS Code popularity, finding an official Linux release for popular GUI software felt like winning the lottery. You'd occasionally see an exuberant front page Reddit post about some random chat client finally releasing a Linux version after 12 years of "coming soon".
Post-Electron it quickly became the norm to support Linux at release and people would expect to see it on day 1. Especially for anything vaguely dev related like the YCombinator startup of the week.
And it would have 1:1 feature parity with the Windows/MacOS version by default, not missing half the features or frozen in time at V1.0 like some "in name only" official Linux ports I remember having the misfortune to use.
It's been memory holed by now after Electron became ubiquitous and associated with bloat. But it (and webapps in general) made a huge difference for "year of the Linux desktop" to be as viable as it is today.
pjmlp
2 days ago
The year of the Linux desktop has been made viable via WSL and Virtualization Framework, or shipping the Linux kernel underneath ChromeOS, WebOS and Android.
Electron has made nothing to change that, only a even worse experience than what GNOME and KDE apps have offered since the early 2000's.
Don't worship stuff like i3 stuck in the 1980 early window managers, and the apps will be there.
hackernud3s
4 days ago
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.
s3p
4 days ago
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.
Grombobulous
4 days ago
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!
Kuraj
4 days ago
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.
Brian_K_White
4 days ago
It was never a good solution and there is no reason to ever stop calling a turd a turd.
bee_rider
4 days ago
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.