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
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.
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.
I use web-tech apps because I have to, and because they're adequate, not because it's an optimal user experience.
When was the last time complaining about this did anything?
They do, but they don't know what's causing it. 8GB of RAM usage for Codex App is clown-level ridiculous.
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.
Are they hurting for customers?
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. -_-
> 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.
Thanks for contributing to the obsolescence cycle.
They're only doing well because of their illegal monopolistic practices not being cracked down on.
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.
But there isn't, not if you include all the extensions and remember the price
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.
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)
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?
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
> reinventing the wheel
what exactly are you inventing by using a framework "invented" decades ago and used by countless apps in all those 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.
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.
- 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.
Which parts in particular do you think electron misses from this list?
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.
These strategies are fine for toy apps but you cannot ship a production app to millions or even thousands of people without these basics.
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.