Comment by OlympicMarmoto
9 hours ago
It is baffling how these AI companies, with billions of dollars, cannot build native applications, even with the help of AI. From a UI perspective, these are mostly just chat apps, which are not particularly difficult to code from scratch. Before the usual excuses come about how it is impossible to build a custom UI, consider software that is orders of magnitude more complex, such as raddbg, 10x, Superluminal, Blender, Godot, Unity, and UE5, or any video game with a UI. On top of that, programs like Claude Cowork or Codex should, by design, integrate as deeply with the OS as possible. This requires calling native APIs (e.g., Win32), which is not feasible from Electron.
It’s just irrelevant for most users. These companies are getting more adoption than they can handle, no matter how clunky their desktop apps are. They’re optimizing for experimentation. Not performance.
While this may be true for casual users, for dev native products like Codex, the desktop experience actually matters a lot. When you are living in the tool for hours, latency, keyboard handling, file system access, and OS-level integration stop being “nice to have” and start affecting real productivity. web or Electron apps are fine for experimentation, but they hit a ceiling fast for serious workflows -- especially if the icp is mostly technical users
Still good enough for the majority of the users.
1 reply →
[flagged]
1 reply →
It's not irrelevant for developers neither for users. Tiktok has shown that users deeply care about the experience and they'll flock en-masse to something that has a good experience.
The experience in the claude app is fine.
More adoption? I don't think so... It feels to me that these models && tools are getting more verbose/consuming more tokens to compensate for a decrease in usage. I know my usage of these tools has fallen off a cliff as it become glaringly obvious they're useful in very limited scopes.
I think most people start off overusing these tools, then they find the few small things that genuinely improve their workflows which tend to be isolated and small tasks.
Moltbot et al, to me, seems like a psyop by these companies to get token consumption back to levels that justify the investments they need. The clock is ticking, they need more money.
I'd put my money on token prices doubling to tripling over the next 12-24 months.
> I'd put my money on token prices doubling to tripling over the next 12-24 months.
Chinese open weights models make this completely infeasible.
6 replies →
I suspect making the models more verbose is also a source of inflation. You’d expect an advanced model to nail down the problem succinctly, rather than spawning a swarm of agents that brute force something resembling an answer. Biggest scam ever.
The situation for Desktop development is nasty. Microsoft had so many halfassed frameworks and nobody knows which one to use. It’s probably the de facto platform on Windows IS Electron, and Microsoft use them often, too.
On MacOS is much better. But most of the team either ended up with locked in Mac-only or go cross platform with Electron.
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.
I built my Block Editor (Notion-style) in Qt C++ and QML[1].
[1] https://get-notes.com
Qt with QML works fine. The real reason is that companies can't hire enough native developers because the skill is comparitively rare.
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.
23 replies →
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.
1 reply →
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.
1 reply →
“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
> 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.
2 replies →
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.
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.
"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
5 replies →
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
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
microsoft also uses react native for the start menu and also bricked that during a recent upgrade apparently... along with breaking other stuff.
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.
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.
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.
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?
That’s what React Native is. But JavaScript is the problem.
- Video games often use HTML/JS-based UI these days.
- UE5 has its own custom UI framework, which definitely does not feel "native" on any platform. Not really any better than Electron.
- You can easily call native APIs from Electron.
I agree that Electron apps that feel "web-y" or hog resources unnecessarily are distasteful, but most people don't know or care whether the apps they're running use native UI frameworks, and being able to reassign web developers to work on desktop apps is a significant selling point that will keep companies coming back to Electron instead of native.
I have been building Desktop apps with Go + Wails[1]. I happen to know Go, but if you are ai-coding even that is not necessary.
A full fledged app, that does everything I want, is ~ 10MB. I know Tauri+Rust can get it to probably 1 MB. But it is a far cry from these Electron based apps shipping 140MB+ . My app at 10MB does a lot more, has tons of screens.
Yes, it can be vibe coded and it is especially not an excuse these days.
[1] https://wails.io/
Microsoft Teams, Outlook, Slack, Spotify? Cursor? VsCode? I have like 10 copies of Chrome in my machine!
I've looked into Tauri and Wails, but they don't seem realistic for a cross-platform app with wide distribution across multiple platforms and platform versions.
One of Electron's main selling points is that you control the browser version. Anything that relies on the system web view (like Tauri and Wails) will either force you to aggressively drop support for out-of-date OS versions, or constantly check caniuse.com and ship polyfills like you're writing a normal web app. It also forces you to test CSS that touches form controls or window chrome on every supported major version of every browser, which is just a huge pain. And you'll inevitably run into bugs with the native -> web glue that you wouldn't hit with Electron.
It is absolutely wasteful to ship a copy of Chrome with every desktop app, but Tauri/Wails don't seem like viable alternatives at the moment. As far as I can tell, there aren't really any popular commercial apps using them, so I imagine others have come to the same conclusion.
2 replies →
I am in love with wails. having python and JS background with no go experience. I pm'ed Ai agents to create a fairly complex desktop app for my own use. it is day and night in terms of performance compared to lightest electron app.
Wails is pretty good. I wrote a couple of apps but since I'm on macOS I ended up rewriting them in SwiftUI and that's much lighter of course since it uses all native APIs.
Interesting. Does the Wails renderer support the full set of what Webkit/Chromium supports?
Wow Wails looks interesting! Hadn't heard of it before.
Given that OpenAI managed to single-handedly triple the price of RAM globally, people will very much care about their chat application consuming what little scraps are left over for them, even if they don't know enough about anything to know why their system is running poorly.
My main take is exactly the opposite. Why not build everything with a simple text interface (shell command) so the models learn to use these tools natively in pretraining. Even TUI like codex-cli or claude code are needless abstractions for such use cases and make full automation hard. You could add as many observability or input layers for humans as you want but the core should be simple calls that are saved in historical and documentation logs. [the headless/noninteractive modes come close, as do the session logs]
It would be cool if I didn't have to worry about whether I was "in" or "out" of the AI TUI. Right now, I need at least two terminals open: One running my shell, that I use to issue shell commands, and one running Claude, where I can't. It would be nice if it could just be my shell, and when I wanted to invoke claude, I'd just type:
Right in the shell.
isn't that what Simon Willison's `llm` does?
edit: [link](https://github.com/simonw/llm)
Most AI agents have a 'bash mode' and, you can use Warp terminal which is terminal first, but easy to activate the AI from the terminal. For example, if you mangle a jq command, it will use AI to suggest the right way to do it.
-p
1 reply →
TUI is easy to train on, but hard to use for users. Part of the reason it’s easier to have LLMs use a bunch of Unix tools for us is that their text interface is tedious and hard to remember. If you’re a top 5% expert in those tools it doesn’t matter as much I guess but most people aren’t.
Even a full-featured TUI like Claude Code is highly limited compared to a visual UI. Conversation branching, selectively applying edits, flipping between files, all are things visual UI does fine that are extremely tedious in TUI.
Overall it comes down to the fact that people have to use TUI and that’s more important than it being easy to train, and there’s a reason we use websites and not terminals for rich applications these days.
I use headless mode (-p) and keep my named shell histories as journals (so no curses/TUI or GUI). But session management or branching could improve at the tool level and allow seamless integration with completion tools, which could be a simple fast AI looking at recent sessions or even be visual, say for navigating and extending a particular complex branch of a past session. It is not too hard to work with such shell-based flows within Emacs for me, but it would be nice if there was some standardization effort on the tool fronts and some additional care for future automation. I dont want my AI clicking buttons if it can be precise instead. And I certainly want multithreading. I think of AI more as an OS; it needs a shell more than it needs windows at this point in time.
I agree. I like using Claude or Codex in VM on top of the tmux. Much more flexibility that way. I open a new tmux window for each issue/task big enough to warrant it, issue a prompt to create a worktree and agents and let them go to town. I actually use claude and codex a the same time. I still get observability because of tmux and I can close my laptop and let them cook for a while in yolo mode since the VM is frequently backed up in proxmox pbs. I am a retired hobbyist but this has been a nice force multiplier without devolving a complete viby mess. I hope these new orchestration tool support this like vs code remote development does. Same for cloud. I want them to support my personal "cloud" instead of laggy github mess.
I feel like it's because of the way they are internally structured. They have some people who are machine learning trained on post-training, and other people who have nice product management resumes. The post-training people want more compute, well-formatted data, honestly more ways to try whatever technique of reinforcement learning they want.
The product people are building things, but OpenAI has literally been throwing stuff at the wall and it hasn't been sticking. They seem to be behind in terms of everything user interface. Canvas came after Anthropic had artifacts. Codex came after Anthropic had Claude Code.
Some of their researchers (okay one) have (has) stated they believe in interface work. That's because GUIs help engage the person beyond thought, and help the person work with more complexity (perception, physics, form, 3D). But they're playing catchup, or they're trying to incubate wins in science / math.
> even with the help of AI.
This is what you get when you build with AI, an electron app with an input field.
Doesn't have to be. I just revived one of my C++ GLFW app from 2009. Codex was able to help me get it running again and added some nice new features.
I guess you get an Electron app if you don't prompt it otherwise. Probably because it's learned from what all the humans are putting out there these days.
That said.. unless you know better, it's going to keep happening. Even moreso when folks aren't learning the fundamentals anymore.
I've done way, way more than that, as I'm sure others have too.
This is just bad product management.
So where is all this amazing software that you and others built with AI?
All I see is hype blog posts and pre-IPO marketing by AI companies, not much being shipped though.
10 replies →
Their goal is to ship as fast as possible b/c they don't care about what you care about. Their objective is to gather as much data as possible & electron is good enough for that.
6 replies →
Claude code is perfectly capable of writing low level rendering and input code and it can be equally as mindless as vibe coding web apps.
E.g. just say "write a c++ gui widget library using dx11 and win32 and copy flutters layout philosophy, use harfbuzz for shaping, etc etc"
At the end of the day LLMs just reproduce the consensus of the internet, so it makes sense that a coding agent would spit out software that looks like most of what's on the internet.
LLM output is called slop for a reason.
What features are they missing that a native app would allow for?
No-one outside of a small sliver of the tech community cares if an app is built with web tech
Electron also opens up easier porting to Linux which almost certainly wouldn't happen if companies insist on native only
Users care about performance and jank, it’s just that they’ve been successfully forced to shut-up-and-deal-with-it. They’re not involved in purchasing or feedback, and the people that are don’t use it enough to care, or just don’t care. Users who complain about it may as well shout into the void for how much companies take note, but hey, at least we got an ai button now!
Atlassian products are a great example of this. Everyone knows Atlassian has garbage performance. Everyone complains about it. Never gets fixed though. Everyone I know could write customer complaints about its performance in every feedback box for a year, and the only thing that would happen is that we’d have wasted our own time.
Users _care_ about this stuff. They just aren’t empowered to feedback about it, or are trained to just sigh and put up with it.
I find outside of specific use cases the performance and jank are down to the developers and not whether it's native or not
Obsidian is an Electron app which is pretty much universally loved. We can both give single examples
“They just aren’t empowered to feedback about it, or are trained to just sigh and put up with it” is a roundabout way of saying users don’t care about it enough.
i think you've to be more nuanced here - perf becomes important only on the extreme. i think there are compromises to be made between perf and go-to-market.
> This requires calling native APIs (e.g., Win32), which is not feasible from Electron.
That is not correct. One of the major selling points of Electron is precisely that you can call native APIs.
Desktop GUI is a lost art. Gen X were the last people to master it.
I am a gen X, this hurts, but it might be true :(
Why would widgets and buttons be better than a console, and or voice?
Because you see stuff before you decide what to invoke?
This is what happens when an entire generation of programmers doesn’t know how to write code in any language other than JavaScript or maybe Python.
How far from grace we have fallen :sob:
What if they kept the 'good stuff' from us? Does that seem likely here?
Unpopular opinion: why would you want a "native app"? On macOS, basically every app Apple makes themselves is worse in terms of design, usability, and performance than a popular Electron-based alternative.
For example, I tried opening a 200MB log file in Apple's Console.app and it hung. Opened right up in VS Code.
What is the superior Electron based alternative to Pixelmator Pro? Final Cut? Logic? Pages?