This is another common excuse.

You don't need to use microsoft's or apple's or google's shit UI frameworks. E.g. see https://filepilot.tech/

You can just write all the rendering yourself using metal/gl/dx. if you didn't want to write the rendering yourself there are plenty of libraries like skia, flutter's renderer, nanovg, etc

Customers simply don't care. I don't recall a single complain about RAM or disk usage of my Electron-based app to be reported in the past 10 years.

You will be outcompeted if you waste your time reinventing the wheel and optimizing for stuff that doesn't matter. There is some market for highly optimized apps like e.g. Sublime Text, but you can clearly see that the companies behind them are struggling.

>Customers simply don't care. I don't recall a single complain about RAM or disk usage of my Electron-based app to be reported in the past 10 years.

I see complains about RAM and slugginess against Slack and countless others Electron apps every fucking day, same as with Adobe forcing web rendered UI parts in Photoshop, and other such cases. Forums are full of them, colleagues always complain about it.

How are Adobe and Slack/Salesforce doing?

Are they hurting for customers?

the people that USE the software the most are not the people BUYING the software. it’s why all enterprise software has trash UX.

do you think i as a software engineer like using Jira? Outlook? etc? Heck even the trendy stuff is broken. Anthropic took took 6 months to fix a flickering claude code. -_-

Yes that was my point.

Not relevant point though. I was answering to this "I don't recall a single complain about RAM or disk usage of my Electron-based app to be reported in the past 10 years", I wasn't arguing that such apps don't make money.

McDonald’s isn’t hurting for customers either. Doesn’t mean their food is anything a chef ought to aspire to.

Neither it means that McDonald's should aspire to be a chef

Sure, aspiring to mediocrity at a cost to others is a choice.

McDonald's is renown for speed of service, a bit ironic to compare that to slow apps

Maybe 40 years ago.

I'm loving it

Of course they complain about them, but those are the users, not the purchasers.

> I don't recall a single complain about RAM or disk usage of my Electron-based app to be reported in the past 10 years.

When was the last time complaining about this did anything?

Not seeing complaints doesn't mean they don't exist. Not to mention ui latency that is common in electron apps that is just a low-level constant annoyance.

I have complained about literally every Electron based app I have ever used. How would you know there are no complaints?

There are complaints and then users keep using these super popular and bloated apps. Techies make it seem like bloat is a capital sin but it isn't.

When given the option, I never use such apps. I am rarely given the option, however.

Q.e.d.

He who holds the purse strings, decides. The people who pay to have the apps made get to decide and they have decided that what geeks want doesn't matter.

And every time a geek tries to change that, he only wins for a short while and then we're back to the primordial soup.

Oh, and regular users obviously don't care enough.

The various GPU-accelerated terminal projects always make me chuckle

Not sure why, terminals are literally GPU accelerated text rendering solutions since the very beginning of rendering text

Heck, not even just a separate card or whatever, back in the terminal days where you practically had a whole separate small computer just to display the output of the bigger computer on a screen instead of paper.

> Customers simply don't care.

They do, but they don't know what's causing it. 8GB of RAM usage for Codex App is clown-level ridiculous.

I don't bother complaining about Electron-based applications to the developer, and I expect that's not an unusual position. It's not like the downsides are hidden, unique, or a surprise, and if the developers' priorities aligned with ours, they wouldn't have picked electron in the first place.

I use web-tech apps because I have to, and because they're adequate, not because it's an optimal user experience.

> Customers simply don't care. I don't recall a single complain about microplastics in the past 10 years.

> You will be outcompeted if you waste your time reinventing the wheel and optimizing for stuff that doesn't matter. There is some market for safe, environmentally-friendly products, but you can clearly see that the companies that make them are struggling.

ok.

I care. I refuse to use Electron slop unless it is literally the only option available (usually due to some proprietary locked-in platform eg Discord). I will happily pay significant sums of money for well-made native apps that often have fewer features than the Electron versions, simply for the pleasure of using tools that integrate seamlessly with my operating system. Not all of us have given up on software quality.

I don’t complain about Electron because I didn’t install the app if I could avoid it.

They don’t care, or they don’t know? What they do know is their computer that’s only 5 years old goes to shit with only a few apps open. Time for a new laptop.

Thanks for contributing to the obsolescence cycle.

Do a search for "Microsoft teams slow crash" and you'll find a billion complaints by normies.

They're only doing well because of their illegal monopolistic practices not being cracked down on.

Even with SublimeText, most popular IDE is VSCode, most popular interface design tool Figma, all popular chat platforms and so on are all electron based. If people were desperate for faster platforms they'll be migrating to them.

Your mistaking supply-side path dependent outcomes that produce a lack of consumer choice with consumer preference. No consumer prefers slow, bloated, non-native software, but they're stuck with what they can get.

There is competition for Figma. Sketch.

There's plenty of competition for VSCode too.

Don't forget that these Electron apps outcompeted native apps. Figma and VSCode were underdogs to native apps at one point. This is why your supply side argument doesn't make any sense.

> There's plenty of competition for VSCode too.

But there isn't, not if you include all the extensions and remember the price

So an Electron app won. Seems like Electron wasn't a hinderance.

Sure, you can ignore that it was a hindrance just like you ignored ignored the previous point.

Like how you ignored my point too?

If it was a hindrance, why did it win?

Seems clear to me that Electron's higher RAM usage did not affect adoption. Instead, Electron's ability to write once and ship in any platform is what allowed VSCode to win.

> Like how you ignored my point too?

No, differently

> If it was a hindrance, why did it win?

Because reality is not as primitive as you portray it to be, you can have hindrances and boosts with the overall positive even winning effect? That shouldn't be that hard!

> Seems clear to me that Electron's higher RAM usage did not affect adoption.

Again, it only seems clear because you ignore all the dirt, including basic things (like here, it's not just ram, is disk use, startup speed, but also like before with competition) and strangely don't consider many factors.

> Instead, Electron's ability to write once and ship in any platform is what allowed VSCode to win.

So nothing to do with it using the most popular web stack, meaning the largest pool of potential contributors to the editor or extensions??? What about other cross platform frameworks that also allowed that??? (and of course it's not any platform, just 3 desktop ones where VSc runs)

  So nothing to do with it using the most popular web stack, meaning the largest pool of potential contributors to the editor or extensions??? What about other cross platform frameworks that also allowed that??? (and of course it's not any platform, just 3 desktop ones where VSc runs)

I'm not even sure what you're arguing at this point.

Are you arguing that Electron helped VSCode win or what? Because Electron being able to use a popular web stack is also a benefit.

What is your point?

all the extensions followed popularity and ease of development. So, cart horse.

> Even with SublimeText, most popular IDE is VSCode

What a weird comparison, one is free, another one is a premium app, of course a lot of people prefer some suffering over paying money

That just means your feedback system is trash if it fails to surface such an obvious and common pain point in user experience. Tough that's an extremely common state of feedback systems. But also, the general computer knowledge isn't that high for every end user to connect some sluggishness in another app to your app wasting ram and causing disk swaps, that eliminates a lot of end user complaints

> reinventing the wheel

what exactly are you inventing by using a framework "invented" decades ago and used by countless apps in all those years?

> Customers simply don't care. I don't recall a single complain about RAM or disk usage of my Electron-based app to be reported in the past 10 years.

Nothing is worse than reading something like this. A good software developer cares. It’s wrong to assume customers don't care simply because they don't know what's going on under the hood. Considering the downsides and the resulting side effects (latency, more CPU and RAM consumption, fans spinning etc.), they definitely do care. For example, Microsoft has been using React components in their UI, thinking customers wouldn’t care, but as we have been seeing lately, they do care.

Because there is no point in reporting such complains. Just a waste of time.

People absolutely care, but the issue is that no single company/app is really responsible. It's the tragedy of the commons, but for users RAM. No one electron app uses all the RAM, but just a couple are enough to make a common 16GB machine slow down massively.

How is File Pilot for accessibility and for all of the little niceties like native scrolling, clipboard interaction, drag and drop, and so on? My impression is that the creator is has expertly focused on most/all of these details, but I don't have Windows to test.

I insist on good UI as well, and, as a web developer, have spent many hours hand rolling web components that use <canvas>. The most complicated one is a spreadsheet/data grid component that can handle millions of rows, basically a reproduction of Google Sheets tailored to my app's needs. I insist on not bloating the front-end package with a whole graph of dependencies. I enjoy my NIH syndrome. So I know quality when I see it (File Pilot). But I also know how tedious reinventing the wheel is, and there are certain corners that I regularly cut. For example there's no way a blind user could use my spreadsheet-based web app (https://github.com/glideapps/glide-data-grid is better than me in this aspect, but there's no way I'm bringing in a million dependencies just to use someone else's attempt to reinvent the wheel and get stuck with all of their compromises).

The answer to your original question about why these billion dollar companies don't create artisanal software is pretty straightforward and bleak, I imagine. But there are a few actually good reasons not to take the artisanal path.

File pilot is extremely good in my experience, literally the only issue is it doesn't display the sync status on icons in a Dropbox folder.

> You don't need to use microsoft's or apple's or google's shit UI frameworks. E.g. see https://filepilot.tech/

That's only for Windows though, it seems? Maybe the whole "just write all the rendering yourself using metal/gl/dx" is slightly harder than you think.

The proof that rendering is not _that_ hard because the flutter team did it when they switched off skia (although technically they still use skia for text rendering, I'll admit that text rendering and layout is hard)

How is a fact that someone did something proof that it isn’t hard?

I mean, every cross-platform commercial DAW manages to do it? Bitwig, Renoise, Reaper, even VCV.

[delayed]

It's essentially asking application developers to wipe ass for OS developers like Microsoft. It's applaudible when you do it, understandable when you don't.

Even though OpenAI has a lot of cash to burn, they're not in a good position now and getting butchered by Anthropic and possibly Gemini later.

If any major player in this AI field has the power to do it's probably Google. But again, they've done the Flutter part, and the result is somewhat mixed.

At the end of the day, it's only HN people and a fraction of Redditors who care. Electron is tolerated by the silent majority. Nice native or local-first alternatives are often separate, niche value propositions when developers can squeeze themselves in over-saturated markets. There's a long way before the AI stuff loses novelty and becomes saturated.

They’re all iterating products really fast. This Codex is already different than the last Codex app. This is all disposable software until the landscape settles.

I'd love to see some opensource projects actually do a good job of this. Its a lot of work, especially if you want:

- Good cross platform support (missing in filepilot)

- Want applications to feel native everywhere. For example, all the obscure keyboard shortcuts for moving around a text input box on mac and windows should work. iOS and Android should use their native keyboards. IME needs to work. Etc

- Accessibility support for people who are blind and low vision. (Screen readers, font scaling, etc)

- Ergonomic language bindings

Hitting these features is more or less a requirement if you want to unseat electron.

I think this would be a wonderful project for a person or a small, dedicated team to take on. Its easier than it ever used to be thanks to improvements in font rendering, cross platform graphics libraries (like webgpu, vulcan, etc) and improvements in layout engines (Clay). And how much users have dropped their standards for UI consistency ever since electron got popular and microsoft gave up having a consistent UI toolkit in windows.

There are a few examples of teams doing this in house (eg Zed). But we need a good opensource project.

But Electron doesn’t hit that bar even

yep, you're right to call that.

It gets pretty close.

Which parts in particular do you think electron misses from this list?

We're actually working on a native open source cross-platform UI toolkit called Slint that’s trying to do exactly that. https://slint.dev

“Render yourself with GPU APIs” has all the same problems with a11y, compatibility, inconsistent behaviour that electron has - the only one it might fix is performance and plenty of apps have messed that one up too

That'll work great until your first customer from a CJK or RTL language writes in, "Hey, how come I can't type in your app?", or the blind user writes in "Hey how come your app is completely blank?" then you'll be right in the middle of the "Find Out" phase

These strategies are fine for toy apps but you cannot ship a production app to millions or even thousands of people without these basics.

"native" is used for different things, from "use the platform's default gui toolkit" to "compile to a machine code binary". the former is a bit of a mess, but the latter is strictly better than wrapping a web view and shipping an entire chrome fork to display and interpret it. just write something in qt and forget about native look and feel, and the performance gain will be enough to greatly improve the user experience.

Should just use javafx or swing. Take a leaf out of intellij which while it as it's own performance problems (although not from the fact of the ui framework) has a fantastic ui across Mac / windows / nix

I can’t tell if this word salad is sarcasm or genuine.

From the suggestions it looks like sarcasm, but you never can tell these days

Non-native UI widgets, non-native runtime, non-native language

Java swing is way underrated despite being very complex. It baffles me why this just sort of withered on the vine.

(I was a swing developer for several years)

The web sucked all the oxygen out of the room.

It really was Oracle’s fault – they neglected deployment for too long. Deploying Java applications was simply too painful, and neither JLink nor JPackage existed.

microsoft also uses react native for the start menu and also bricked that during a recent upgrade apparently... along with breaking other stuff.

As I outlined in a sibling comment. You can still use React and your JS developers. Just don't ship a whole browser with your app.

May be an app that is as complex as Outlook needs the pixel-perfect tweaking of every little button that they need to ship their own browser for exact version match. But everything else can use *system native browser*. Use Tauri or Wails or many other solutions like these

That said, I do agree on the other comments about TUIs etc. Yes, nobody cares about the right abstractions, not even the companies that literally depend on automating these applications

Given how much money they have, and the reach they're attempting to achieve, is it really asking too much that they hire native development teams? It's not like an application of this scale requires an army of engineers.

Do not give a shit about how they excuse doing a bad job. If their tools make them that much more productive, and being the developer of those tools should allow you to make great use of them.

Use native for osx Use .Net framework for windows Use whatever on Linux.

Its just being lazy and ineffective. I also do not care about whatever "business" justification anyone can come up with for half assing it.

This. Even Linux is nasty. Qt and GTK are both horrible messes to use.

It would be nice if someone made a way to write desktop apps in JavaScript with a consistent, cross-platform modern UI (i.e. swipe to refresh, tabs, beautiful toggle switches, not microscopic check boxes) but without resorting to rendering everything inside a bloated WebKit browser.

That’s what React Native is. But JavaScript is the problem.

Qt is not a horrible mess to use, the problem is just people don't bother to learn any tech stack outside web. It's so obvious that this is the issue to anybody who actually does native development.

Can you explain why GTK is a mess?

These companies have BILLIONS of dollars and some of the smartest people in the world and access to bleeding edge AI

There should be no excuses! Figure it out!

it'll be the least important thing to do

Win32 is the platform to use on Microsoft Windows. Everything else is built on top of it. So it will (a) work (b) be there forever.

I guess it shows how geriatric I am with desktop app development these days, but does no one use Qt anymore? Wasn't the dream for that to be a portable and native platform to write GUI apps? Presumably that could abstract away which bullshit Microsoft framework they came out with this week.

I haven't touched desktop application programming in a very long time and I have no desire to ever do so again after trying to learn raw GTK a million years ago, so I'm admittedly kind of speaking out of my ass here.

Qt means C++. I'll take Typescript over C++ for a GUI task any day.

Qt is also pretty memory-hungry; maybe rich declarative (QML) skinnable adaptable UIs with full a11y support, etc just require some RAM no matter what. And it also looks a wee bit "non-native" to purists, except on Windows, where the art of uniform native look is lost.

Also, if you ever plan extensions / plugin support, you already basically have it built-in.

Yes, a Qt-based program may be wonderfully responsive. But an Electron-based app can be wonderfully responsive, too. And both can feel sluggish, even on great hardware. It all depends on a right architecture, on not doing any (not even "guaranteed fast") I/O in the GUI thread, mostly. This takes a bit of skill and, most importantly, consideration; both are in short supply, as usual.

The biggest problem with Electron apps is their size. Tauri, which relies on the system-provided web view component, is the reasonable way.

I don't get this HN worship of Qt. Have you ever used Qt apps on macOS? They don't feel native at all. They feel sort-of native-emulating in the same way wxWidgets apps on macOS feel: they use native controls but all the little details including design language are off.

I'm not saying this is a huge problem for me even if it bothers me personally. But if you're here on HN advocating native over Electron, then it seems logical to me that you would care about being truly native instead of merely "using native controls while feeling off".

This is even before getting to the point that Qt isn't truly native. They just draw controls in a style that looks native, they don't actually use native controls. wxWidgets uses native controls but they don't behave better despite that.

This is not because of Qt - it is due to some (most) Qt developers not caring enough. I created my Qt app feel native both on macOS and Windows[1]. It did require a lot of tuning - but those are things I'll reuse across other apps.

[1] https://get-notes.com/

god damn, I've never though Qt app could be this smooth and looking nice.

They don’t look native on Windows, either.

Qt is still used, but I think part of the reason it is less used is that C++ isn't always the right language anymore for building GUI application.

That’s actually why we're working on Slint (https://slint.dev): It's a cross-platform native UI toolkit where the UI layer is decoupled from the application language, so you can use Rust, JavaScript, Python, etc. for the logic depending on what fits the project better.

How can C++ not be the "right" language? It seems to meet all the requirements for event-driven GUIs - event handlers are function callbacks after all...

C++ works, but compared to other languages it's often no longer the most productive choice for UI work. Modern UI code is mostly glue and state management, where fast iteration matters more than squeezing out maximum performance. And when performance does matter, there are also newer, safer languages.

For teams comfortable with C++ or with existing C++ libraries to integrate, it can of course still be a strong choice, just not the preferred one for most current teams.

But desktop C++ isn't difficult or slow to write...

It seems odd to me that the software world has gone in the direction of "quick to write - slow to run". It should be the other way around. Things of quality (eg. paintings by Renaissance masters) took time to create, despite being quick to observe.

It also seems proven that releasing software quickly ("fast iteration") doesn't lead to quality - see how many releases of the YouTube app or Netflix there are on iOS or Android; if speedy releases are important, it is valuing rush to production over quality, much like a processed food version of edible content.

In a world that is also facing energy issues, sluggish and inefficient performance should be shunned, not welcomed?

I suppose this mentality is endemic, and why we see a raft of cruddy slow software these days, where upcoming developers ("current teams") no longer value performance over ease of their job. It can only get worse if the "it's good enough" mentality persists. It's quite sad.

The part that takes time in UI isn’t wiring up components, it’s the small changes like something is a pixel to the right or that gap is two pixels wide. Changing those in a C++ project means recompiling and that adds up to significant overhead over a day of polishing the UI. If C++ was able to get builds out in less than a second, this wouldn’t be an issue. People value performance in their own tools more than the tools of their customer.

In modern Qt you don't write UI in C++ anymore - you do that in QML. It is far simpler to create amazing pixel perfect UIs with drooling-inducing animations in QML. I wrote a blog post that talks a bit about this[1].

[1] https://rubymamistvalove.com/block-editor

In wxWidgets you use sizers, so you don't work on pixel-level alignments. I can understand if you're using an ancient framework like MFC, but even then I seem to recall there was a sizer equivalent system (or it is easy enough to write a class to do so, moving components).

I think it is a daft thing to move to shipping a colossal web framework and entire browser simply because of 1px UI alignments (which have been a solved problem for decades in C++ anyway).

Qt is still pretty good, but it's dated in comparison to newer frameworks like Flutter and React Native. No hot reloading of changes, manual widget management vs. React where you just re-define the whole UI every frame and it handles changes magically, no single source of truth for state, etc.

That's false, see QML hot reload[1].

[1] https://www.qt.io/blog/speed-up-qt-development-with-qml-hot-...

That's a third party paid addon. Hardly a fair comparison.

And GTK4 is even very usable from Rust too. It’s not a bad development experience, but these companies probably find 100 webdevs for every system programmer.

Come on GUI apps are not systems programming, what's with this title inflation.

I didn't want to call it backend, because it's not that. Maybe desktop programmer? Anyway, if you're doing GUI in Rust or similar, you're at least handling memory and syscalls, which is closer to systems programming, I'd say.

I built my Block Editor (Notion-style) in Qt C++ and QML[1].

[1] https://get-notes.com

One reason why I personally never bothered is the licensing of some of its important parts, which is a choice of either GPL or commercial. Which is fair, but too bothersome for some use-cases (e.g. mobile apps which are inherently GPL-unfriendly). Electron and the likes are typically MIT/BSD/etc licensed.

Qt with QML works fine. The real reason is that companies can't hire enough native developers because the skill is comparitively rare.