Some of the engineers working on the app worked on Electron back in the day, so preferred building non-natively. It’s also a nice way to share code so we’re guaranteed that features across web and desktop have the same look and feel. Finally, Claude is great at it.
That said, engineering is all about tradeoffs and this may change in the future!
I tried the desktop app and was shocked at the performance. Conversations would take a full second to load, making rapidly switching intolerable. Kicking off a new task seems to hang for multiple seconds while I'm assuming the process spins up.
I wanted to try a disposable conversations per feature with git worktree integration workflow for an hour to see how it contrasted, but couldn't even make it ten minutes without bailing back to the terminal.
While there are legitimate/measurable performance and resource issues to discuss regarding Electron, this kind of hyperbole just doesn't help.
I mean, look: the most complicated, stateful and involved UIs most of the people commenting in this thread are going to use (are going to ever use, likey) are web stack apps. I'll name some obvious ones, though there are other candidates. In order of increasing complexity:
1. Gmail
2. VSCode
3. www.amazon.com (this one is just shockingly big if you think about it)
If your client machine can handle those (and obviously all client machines can handle those), it's not going to sweat over a comparatively simple Electron app for talking to an LLM.
Basically: the war is over, folks. HTML won. And with the advent of AI and the sunsetting of complicated single-user apps, it's time to pack up the equipment and move on to the next fight.
This is an important lesson to watch what people do, not what they say.
if that's the case, why don't you just ask it to "make it not shit"?
The sheer speedup all users will show everyone why vibe coding is the future. After all coding is a solved problem.
Migrating the system would be the easier part in that regard, but they'll still need a JS UI unless they develop multiple teams to spearhead various native GUIs (which is always an option).
Almost every AI chat framework/SDK I've seen is some React or JS stuff. Or even agent stuff like llamaindex.ts. I have a feeling AI is going to reinforce React more than ever.
With your context and understanding of the coding agent's capabilities and limitations, especially Opus4.6, how do you see that going?
Huh?
Why does it matter what tech the engineers used in the past? I thought they didn't write code anymore.
Could you visualize the user's usage? For example, like a glass of water that is getting emptier the more tokens are used, and gets refilled slowly.
Because right now I have no clue when I will run out of credits.
Thanks!
I always wonder how those established Electron codebases would map over to something that uses the system specific WebViews and how broken (or not) those would prove to be:
But admittedly that would just decrease the bundle size while doing not much for the performance or resource usage: https://github.com/Elanis/web-to-desktop-framework-compariso... so maybe not super relevant to this particular discussion.
- Using a stack your team is familiar with still has value
- Migrating the codebase to another stack still isn’t free
- Ensuring feature and UX parity across platforms still isn’t free. In other words, maintaining different codebases per platform still isn’t free.
- Coding agents are better at certain stacks than others.
Like you said any of these can change.
It’s good to be aware of the nuance in the capabilities of today’s coding agents. I think some people have a hard time absorbing the fact that two things can be true simultaneously: 1) coding agents have made mind bending progress in a short span 2) code is in many ways still not free
But it should be possible to make an Electron app that is more reliable and eats less resources.
You guys just did add it too, so yeah!
So the model is not a generalised AI then? It is just a JS stack autocomplete?
If you can put in unlimited coding engineering effort, why isn't Claude Code the very best it can possibly be?
Why isn't the fact that it can work 10% better an excuse to get claude to work on it for however long it takes?
I mean, most people here have done development with claude code, and we suppose the answer is simply: because that doesn't work without a capable engineer constantly babysitting the changes it's making, guiding it, nudging it, reminding it about edge cases, occasionally telling it it's being stupid ... it's a great product, incredible even, but it doesn't work without senior engineers.
Same question: Why doesn't it have more plugins and batch script and modfications than the app store? Surely it can by itself come up with 10000 good ideas and just implement them? Everything from little games to how to active bedroom lights by chinese vendor #123891791 ?
It's the fastest way to iterate because Electron is the best cross platform option and because LLMs are likely trained on a lot of HTML/Javascript.
Which is why Claude is great at it.
I'm glad to see this coming from a company that is so popular these days.
Thanks!
I can see it in my team. We've all been using Claude a lot for the last 6 months. It's hard to measure the impact, but I can tell our systems are as buggy as ever. AI isn't a silver bullet.
When devs outsource their thinking to AI, they lose the mental map, and without it, control over the entire system.
Use AI as a sanity check on your thinking. Use it to search for bugs. Use it to fill in the holes in your knowledge. Use it to automate grunt work, free your mind and increase your focus.
There are so many ways that AI can be beneficial while staying in full control.
I went through an experimental period of using Claude for everything. It's fun but ultimately the code it generates is garbage. I'm back to hand writing 90% of code (not including autocomplete).
You can still find effective ways to use this technology while keeping in mind its limitations.
It’s easy to see the immediate speed boost, it’s much harder to see how much worse maintaining this code will be over time.
What happens when everyone in a meeting about implementing a feature has to say “I don’t know we need to consult CC”. That has a negative impact on planning and coordination.
An engineer should be code reviewing every line written by an LLM, in the same way that every line is normally code reviewed when written by a human.
Maybe this changes the original argument from software being “free”, but we could just change that to mean “super cheap”.
https://imgur.com/gallery/i-m-stupid-faster-u8crXcq
(sorry for Imgur link, but Shen's web presence is a mess and it's hard to find a canonical source)
I'm not saying this is completely the case for AI coding agents, whose capabilities and trustworthiness have seen a meteoric rise in the past year.
And now the comments are "If it is so great why isn't everything already written from scratch with it?"
Of course the answer is all the things that aren't free, refinement, testing, bug fixes, etc, like the parent post and the article suggested.
For my own work I've focused on using the agents to help clean up our CICD and make it more robust, specifically because the rest of the company is using agents more broadly. Seems like a way to leverage the technology in a non-slop oriented way
I'm currently building a macOS AI chat app. Generally SwiftUI/AppKit is far better than Web but it performs bad in few areas. One of them is Markdown viewer. Swift Markdown libraries are slow and lacks some features like Mermaid diagrams. To work around this, some of my competitors use Tauri/Electron and few others use WKWebView inside Swift app.
Initially I tried WKWebView. Performance was fine and the bridge between JS and Swift was not that hard to implement but I started seeing few problems especially due to the fact that WebView runs as separate process and usually a single WebView instance is reused across views.
After few attempts to fix them, I gave up the idea and tempted to go fully with Web rendering with Tauri but as a mac developer I couldn't think about building this app in React. So I started building my own Markdown library. After a month of work, I now have a high-performance Markdown library built with Rust and TextKit. It supports streaming and Markdown extensions like Mermaid.
Most of the code was written by Claude Opus, and some tricky parts were solved by Codex. The important lesson I learned is that I’m no longer going to accept limitations in tech and stop there. If something isn’t available in Swift but is available in JS, I’m going to port it. It’s surprisingly doable with Claude.
Using IntelliJ I actually find myself wishing for an integrated webview of Github Copilot. The native view is absolutely terrible, jumping up and down non stop.
Edit: The title of the post originally started with "If code is free,"
it just means that it might be free for my owner to adopt me, but it sure as hell aint free for them to spoil me
- AI bad - JavaScript bad - Developers not understanding why Electron has utility because they don't understand the browser as a fourth OS platform - Electron eats my ram oh no posted from my 2gb thinkpad
You mean incongruent styles? As in, incongruent to the host OS.
There is no doubt electron apps allow the style to be consistent across platforms.
Code is not the cost. Engineers are. Bugs come from hindsight not foresight. Let’s divide resources between OSs. Let all diverge.
> They are often laggy or unresponsive. They don’t integrate well with OS features.
> (These last two issues can be addressed by smart development and OS-specific code, but they rarely are. The benefits of Electron (one codebase, many platforms, it’s just web!) don’t incentivize optimizations outside of HTML/JS/CSS land
Give stats. Often, rarely. What apps? I’d say rarely, often. People code bad native UIs too, or get constrained in features.
Claude offer a CLI tool. Like what product manager would say no to electron in that situation.
This article makes no sense in context. The author surely gets that.
This is based on the premise that LLM-corpos are right. And if they are wrong, then the laughs about their hypocrisy is doubly deserved :) .
>There are downsides though. Electron apps are bloated; each runs its own Chromium engine. The minimum app size is usually a couple hundred megabytes. They are often laggy or unresponsive. They don’t integrate well with OS features.
A few hundred megabytes to a few gb sounds like an end user problem. They can either make room or not use your application.
You can easily buy a laptop for around 400 USD that will run Claude code just fine, along with several other electron apps.
Don't get me wrong, native everything ( which would probably mean sacrificing Linux support) would be a bit better, but it's not a deal breaker.
Should they have re-written Chromium too?
I didn’t say AI was bad and I acknowledged the benefits of Electron and why it makes sense to choose it.
With 64gb of RAM on my Mac Studio, Claude desktop is still slow! Good Electron apps exist, it’s just an interesting note give recent spec driven development discussion.
It's pretty easy to argue your point if you pick a strawman as your opponent.
They have said that you can be significantly more productive (which seems to be the case for many) and that most of their company primarily uses LLM to write code and no longer write it by hand. They also seems to be doing well w.r.t. competition.
There are legitimate complaints to be made against LLMs, pick one of them - but don't make up things to argue against.
You can use those expensive engineers to build more stuff, not rewrite old stuff
All technology choices are about trade-offs, and while our desktop app does actually include a decent amount of Rust, Swift, and Go, but I understand the question - it comes up a lot. Why use web technologies at all? And why ship your own engine? I've written a long-form version of answers to those questions here: https://www.electronjs.org/docs/latest/why-electron
To us, Electron is just a tool. We co-maintain it with a bunch of excellent other people but we're not precious about it - we might choose something different in the future.
If as your CEO says “coding is largely solved”, why is this the case?
Or is your CEO wrong and coding is not largely solved?
Given how much they pay their developers, the Claud app probably cost at least 2, and likely 3, orders of magnitude more to build.
If their AI could do the same for $2m they'll definitely do that any day.
Also if you haven't heard, disk space is no longer as cheap, and RAM is becoming astoundingly expensive.
Tauri's story with regards to the webview engine on Linux is not great.
Claude is going to help mostly with code, much less with design. It might help to accelerate integration, if the application is simple enough and the environment is good enough. The fact is, going cross-platform native trebles effort in areas that Claude does not yet have a useful impact.
The disturbing fact is that AI is simply smarter than us by a stupendous margin. Anything you do that involves thinking can be done better by the AI. We are obsolete when it comes to being smart.
I was in denial about this for a couple years, but I understand now.
The app handles NuGet dependency resolution on the fly, catches runtime errors and feeds them back to the model for self-correction, and can export standalone executables (WPF for Windows, Avalonia for cross-platform). Everything is self-contained — users don't need to install any SDKs, IDEs, or toolchains.
I'm a teacher, not a startup founder, and I've been trying to market this commercially without much luck. Seriously considering open-sourcing the whole thing. Would love to hear what people here think about the native-vs-web approach for AI-generated applications.
Happy to do a quick demo if anyone's curious.
I've been building a native macOS/iOS app that lets me manage my agents. Both the ability to actually control/chat fully from the app and to just monitor your existing CLI sessions (and/or take 'em over in the app).
Terrible little demo as I work on it right now w/claude: https://i.imgur.com/ght1g3t.mp4
iOS app w/codex: https://i.imgur.com/YNhlu4q.mp4
Also has a rust server that backs it so I can throw it anywhere (container, pi, etc) and the connect to it. If anyone wants to see it, but I have seen like 4 other people at least doing something similar: https://github.com/Robdel12/OrbitDock
Also AI is better at beaten path coding. Spend more tokens on native or spend them on marketing?
Computers have gotten orders of magnitude faster since 2016, but using mainstream apps certainly don't feel any faster. Electron and similar frameworks do offer appealing engineering tradeoffs, but they are a main culprit of this problem.
Sure, the magnitude of RAM/compute "waste" may have grown from kB to MB, but inefficiency is still inefficiency - no matter how powerful the machine it's running on is.
If only AI had more Liquid Glass, lol
I hope that prevalence of AI coding agents might lead to a bit of a revival of RAD tools like lazarus, which seem to me to have a good model for creating cross-platform apps.
Then what?
Not saying I'm not using AI - because I am. I'm using it in the IDE so I can stay close to every update and understand why it's there, and disagree with it if it shouldn't be there. I'm scared to be distanced from the code I'm supposed to be familiar with. So I use the AI to give me superpowers but not to completely do my job for me.
We'll see, I guess...
We should refuse to accept coding agents until they have fully replaced chromium. By that point, the world will see that our reticence was wisdom.
Really and truly, what do we KNOW about Anthropic because the Claude desktop app is an electron app?
I submit the answer is “very very little.” But the author and lots of people in this thread seem willing to infer quite a fucking lot!
I guess I don't understand how people don't see something like 20k + an engineer-month producing CCC as the actual flare being shot into the night that it is. Enough to make this penny ante shit about "hurr hurr they could've written a native app" asinine.
They took a solid crack at GCC, one of the most complex things *made by man* armed with a bunch of compute, some engineers guiding a swarm, and some engineers writing tests. Does it fail at key parts? Yes. It is a MIRACLE and a WARNING that it exists at all? YES. Do you know what you would have with an engineer-month and 20k in compute trying to write GCC from scratch in 2 weeks in 2024? A whole heck of a lot less than they got.
This notion that everything is the same just didn't make contact on 2025, and we're in 2026 now. All of software is already changing and HN is full of wanking about all the wrong stuff.
You would think with programming becoming completely automated by the end of 2026, there'd be a vibe coded native port for every platform, but they must be holding back to keep us from all getting jealous.
You just have to be really careful because the agent can easily slip into JS hell; it has no shortage of that in its training.
And despite what Anthropic and OpenAI want you to think, these LLMs are not AGI. They cannot invent something new. They are only as good as the training data.
- unlike QT it's free for commercial use.
- I don't know any other user land GUI toolkit/compositor that isn't a game engine(unity/unreal/etc).
You're easy to impress, that explains the unrealistic expectations "on the surface". That's some strange analogy, though, basic usability is the first mile, not the last. Coming back to the frameworks and apps, the last mile would be respecting Mac unique keyboard bindings file for text editing. First mile is reacting to any keyboard input in a text field. Same with the compiler, basic hello world fail isn't the last mile.
I only see these complaints on HN. Real users don't have this complaint. What kind of low-end machines are you running, that Chromium engine is too heavy for you?
> They are often laggy or unresponsive.
That's not due to Electron.
> They don’t integrate well with OS features.
If it is good enough for Microsoft Teams it is probably good enough for most apps. Teams can integrate with microphone, camera, clipboard, file system and so on. What else do you want to integrate with?
Not everyone is running the latest and greatest hardware, very few actually have the money for that. If you're running hardware from before this decade, or especially the early 2010s, the difference between an Electron app and a native app is unbelievably stark. Electron will often bring the device to its knees.
This is particularly pertinent on bulk-purchased corporate and education machines which are loaded down with mandated spyware and antivirus garbage and often ship with CPUs that lag many years behind, and in the case of laptops might even have dog slow eMMC storage which makes the inevitable virtual memory paging miserable.
These workers complain about performance on the machines we can afford. 16GB RAM and 256GB SSDs are the standard, as is 500MB/sec. internet for offices with 40 people, and my plans to upgrade RAM this year were axed by the insane AI chip boondoggle.
People on HN need to understand that not everyone works for a well-funded startup, or big tech company that is in the process of destroying democracy and the environment in the name of this quarter's profits!
BTW Teams has moved away from Electron, before it did I had to advise people to use the browser app instead of the desktop for performance reasons.
Real users complain differently: "My machine is slow". Electron itself is not very heavyweight (though not featherweight), but JS and DOM can cost a lot of resources. Right now my GMail tab has allocated 529 MB.
> That's not due to Electron.
Of course, but it takes some careful thought. BTW e.g. Qt apps can be pretty memory-hungry, too.
> good enough for Microsoft Teams
It's not easy no pick a more "beloved" application.
What an Electron app usually would miss is things like global shortcuts managed by macOS control panel, programmability via Automation, and the L&F of native controls. I personally don't usually miss any of these, but users who actually like macOS would usually complain.
I personally prefer to run Electron-ish apps, like Slack, in their Web versions, in a browser.
The free ride of ever increasing RAM on consumer devices is over because of the AI hyperscalers buying all fab capacity, leading to a real RAM shortage. I expect many new laptops to come with 8GB as standard and mid-range phones to have 4GB.
Software engineers need to start thinking about efficiency again.
A native app is the wrong abstraction for many desktop apps. The complexity of maintaining several separate codebases likely isn't worth the value add. Especially for a company hemorrhaging money the way the Anthropic does.
I've been building a native macOS AI client in Swift — it's 15MB, provider-agnostic, and open source: https://github.com/dinoki-ai/osaurus
Committing to one platform well beats a mediocre Electron wrapper on all three.
I don't care if it's QT or a WebView or something else, I just want to lower friction for myself
https://www.businessinsider.com/anthropic-claude-code-founde...
It's a nodejs app, and there is no reason to have a problem with that. Nodejs can wait for inference as fast as any native app can.
Also I refuse to download and run Node.js programs due to the security risk. Unfortunately that keeps me away from opencode as well, but thankfully Codex and Vibe are not Node.js, and neither is Zed or Jetbrains products.
Node apps typically have serious software supply chain problems. Their dependency trees are typically unauditable in practice.
A few years ago maybe. Tauri makes better sense for this use case today - like Electron but with system webviews, so at least doesn't bloat your system with extra copies of Chrome. And strongly encourages Rust for the application core over JS/Node.
I use Opus 4.6 (for complex refactoring), Gemini 3.1 Pro (for html/css/web stuff) and GPT Codex 5.3 (workhorse, replaced Sonnet for me because in Copilot it has larger context) mostly.
For small tools. But also for large projects.
Current projects are:
1) .NET C#, Angular, Oracle database. Around 300k LoC.
2) Full stack TypeScript with Hono on backend, React on frontend glued by trpc, kysely and PostgreSQL. Around 120k LoC.
Works well in both. I'm using plan mode and agent mode.
What helps a ton are e2e playright tests which are executed by the agent after each code change.
My only complain is that it tends to get stutters after many sessions/hours. A restart fixes it.
$39/mo plan.
It is easy to crank out a one-off, flashy tool using Claude (to demo its capabilities), which may tick 80% of the development work.
If you've to maintain it, improve, grow for the long haul, good luck with it. That's the 20% hard.
They took the safe bet!
The fact that claude code is a still buggy mess is a testament to the quality of the dream they're trying to sell.
What bugs are you seeing? I use Claude Code a lot on an Ubuntu 22.04 system and I've had very few issues with it. I'm not sure really how to quantify the amount of use; maybe "ccusage" is a good metric? That says over the last month I've used $964, and I've got 6-8 months of use on it, though only the last ~3-5 at that level. And I've got fairly wide use as well: MCP, skills, agents, agent teams...
Yes, feel free to downvote me.
nailing down all the edge cases
The answer of course is that it can’t do it and maintain compatibility between all three well enough as it’s high effort and each has its own idiosyncrasies.
