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!
As a user I would trade fewer features for a UI that doesn't jank and max out the CPU while output is streaming in. I would guess a moderate amount of performance engineering effort could solve the problem without switching stacks or a major rewrite. (edit: this applies to the mobile app as well)
Yeah, I've got a 7950x and 64gb memory. My vibe coding setup for Bevy game development is eight Claude Code instances split across a single terminal window. It's magical.
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.
I also think Steam does a great job a hiding it, and the new recommendation page is really great IMO. Other than some generic AAA, it introduced me to really great games I enjoyed based on my play history.
The more content is available, the more curation is important and IMO their algorithm currently does a good job at it.
There are some odd cases like that, but you can always "Ignore" a game and it'll never show up again. That also feeds into Steams curation for you based on your interests.
There is an issue on their github about flickering they don't seem to care much about. I think most AI CLIs are using the same reactish cli thing called ink and all are having the same problems. opencode moved to a different library (opentui?) and their client seems to be doing much better. ALthough I must say I like to run the opencode cli locally with the web option and connect to it with a web browser. It's very nice. Plus you can code in bed :)
Both Anthropic's and OpenAI's apps being this janky with only basic history management (the search primarily goes by the titles) tells me a lot. You'd think these apps be a shining example of what's possible.
Explains why my laptop turns into a makeshift toaster when the Claude app automatically runs in the background. Even many games don't run that intensively in the background.
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.
I actually avoid using VSCode for a number of reasons, one of which is its performance. My performance issues with VSCode are I think not necessarily all related to the fact that it's an electron app, but probably some of them are.
In any case, what I personally find more problematic than just slowness is electron apps interacting weirdly with my Nvidia linux graphics drivers, in such a way that it causes the app to display nothing or display weird artifacts or crash with hard-to-debug error messages. It's possible that this is actually Nvidia's fault for having shitty drivers, I'm not sure; but in any case I definitely notice it more often with electron apps than native ones.
Anyway one of the things I hope that AI can do is make it easier for people to write apps that use the native graphics stack instead of electron.
VSCode isn't a regular Electron crap application, in fact Microsoft has dozens of out-of-process plugins written in C++, Rust and C# to work around Electron crap issues, also the in-editor terminal makes use of WebGL instead of div and p soup.
Sigh. Beyond the deeply unserious hyperbole, this is a no-true-scotsman. Yes, you can use native APIs in Electron. They can even help. That's not remotely an argument for not using Electron.
> the in-editor terminal makes use of WebGL
Right, because clearly the Electron-provided browser environment was insufficient and needed to be escaped by using... a browser API instead?
Again, folks, the argument here is from existence. If the browser stack is insufficient for developing UIs in the modern world, then why is it winning so terrifyingly?
> Again, folks, the argument here is from existence. If the browser stack is insufficient for developing UIs in the modern world, then why is it winning so terrifyingly?
If McDonald’s hamburgers taste like warmed-over shit, why are they the most popular in the world?
Gen X and Boomers strangely enough managed to write portable native code, across multiple hardware architectures, operating systems and language toolchains.
As is an insurmountable challenge apparently, to master Web UI delivery from system services, daemons to the default browser like UNIX administration tooling.
> complex UI that isn't a frustratingly slow resource hog
Maybe you can give ones of competing ones of comparable complexity that are clearly better?
Again, I'm just making a point from existence proof. VSCode wiped the floor with competing IDEs. GMail pushed its whole industry to near extinction, and (again, just to call this out explicitly) Amazon has shipped what I genuinely believe to be the single most complicated unified user experience in human history and made it run on literally everything.
People can yell and downvote all they want, but I just don't see it changing anything. Native app development is just dead. There really are only two major exceptions:
1. Gaming. Because the platform vendors (NVIDIA and Microsoft) don't expose the needed hardware APIs in a portable sense, mostly deliberately.
2. iOS. Because the platform vendor expressly and explicitly disallows unapproved web technologies, very deliberately, in a transparent attempt to avoid exactly the extinction I'm citing above.
> Maybe you can give ones of competing ones of comparable complexity that are clearly better?
Thunderbird is a fully-featured mail app and much more performant than Gmail. Neovim has more or less the same feature set as VSCode and its performance is incomparably better.
> Thunderbird is a fully-featured mail app and much more performant than Gmail.
TB is great and I use it every day. An argument for it from a performance standpoint is ridiculous on its face. Put 10G of mail in the Inbox and come back to me with measurements. GMail laughs at mere gigabytes.
Verifiably false. Like, this is just trivial to disprove with the "Reload" button in the browser (about 1.5s for me, FWIW). Why would you even try to make that claim?
> Amazon has shipped what I genuinely believe to be the single most complicated unified user experience in human history
OK, I shop at Amazon, am a Prime member, all that stuff, but their web site is horrible. Just pathetic.
I appreciate that they are huge and sell a pretty much incomprehensible number of things, and that what it takes behind the scenes to make it all happen is hugely complex and very impressive on its own terms, but still: the web site is horrible.
Using the terminal in vscode will easily bring the UI to a dead stop. iterm is smooth as butter with multiple tabs and 100k+ lines of scrollback buffer.
Try enabling 10k lines of scrollback buffer in vscode and print 20k lines.
I'm not sure what you're responding to. What I'm describing is my actual experience using Claude, and what I'm hoping for is that they'll spend something like two engineers for a quarter making the app more pleasant to use.
Setting that aside, I think you learned the wrong lesson here. There's no fight. Performance comes from app architecture engineering more than the underlying tools. Building on the trash fire that is the current JS ecosystem may make it harder, true, but apps like VS Code, Discord, Slack, etc show that with enough effort a team can use those tools to deliver something with relatively much better performance. The underlying browser engines are quite sophisticated and very efficient for what they are asked to do, it's just a question of good engineering on top of that. Based on the observable behavior I'm guessing the Claude app is doing something like triggering reflow for the entire chat thread every time they append a few characters to the chat. Totally avoidable.
The big reason web tech is ubiquitous is it has the best properties for distribution. That may last a little while or a long time, but there is no fundamental reason why it's more durable than say Win32 and MFC.
I keep being told by Anthropic and others than these AI coding tools make it effortless to write in new languages and port code from one language to another.
This is an important lesson to watch what people do, not what they say.
But if AI can maintain code bases so easily, why does it matter if there are 3? People use electron to quickly deploy non-native apps across different systems.
Surely, it would be a flex to show that your AI agents are so good they make electron redundant.
But they don’t. So it’s reasonable to ask why that is.
1. Anthropic has no problem burning tens of thousands of dollars of tokens on things that have zero real-world value, such as implementing a C compiler that as far as I can tell they don't intend to be used in the real world - for example, they announced it on Feb 5, promising "Over the coming days, I’ll continue having Claude push new changes if you want to follow along with Claude’s continued attempts at addressing these limitations" but there have been zero code commits since Feb 5 (the day they announced it). Wouldn't it make far more sense for a company to invest tokens into their own product than burning them for something that may be abandoned within hours of launching, with zero ongoing value to their company or their customers?
2. Why do you think it requires "three times the resources" - wouldn't it normally be an incremental amount of work to support additional targets, but not an additional 100% of work for each additional target?
But the one times the resources didn't solve the problem, clearly, since we are talking about it. And they claim that AI makes it trivial to port to do this sort of things so it would not be 3x the resources.
> But if AI can maintain code bases so easily, why does it matter if there are 3? People use electron to quickly deploy non-native apps across different systems.
Because then their competition would work faster than they could and any amount of slop/issues/imperfections would be amplified threefold.
Also there would inevitably be some feature drift - I got SourceTree for my Mac and was surprised to discover that it's actually somewhat different from the Windows version, that was a bit jarring.
I hope that in the next decade we get something like lcl (https://en.wikipedia.org/wiki/Lazarus_Component_Library), but for all OSes and with bindings for all common languages - so we don't have to rely on the web platform for local software, until then developing native apps is a hard sell.
One thing to consider is that "native" apps are considered the gold standard of desktop UIs, but a overwhelming share of users… don’t care. I, for one, don’t necessarily enjoy Qt apps. I think the only one I still use is KeepassXC and it’s trash to me, just slightly better than Keepass2. I much prefer the Bitwarden Electron app.
Given the choice, I often reach for Electron apps because they feel more feature rich, feel better designed in terms of polish (both UI and UX), and I rarely get resource hog issues (Slack is the only offender I can think of among the Electron apps I use)
Did you ever consider that perhaps for other people when something is unreasonably slow and consuming all of their battery, the "polish" is really not that high on the list of important characteristics?
Also, keep in mind that many people would like their applications to respect their preferences, so the "polish" that looks completely out of place on their screen is ugly (besides slow).
Ok but did you consider some people care about polish and prefer apps with an attention to design, and not so much about consistency with other apps? Why are your tastes more important?
Not my taste, the requirements of not crashing and not being horribly slow come before any polish. Any software engineering course will teach you that.
Yeah, I'm kind of disheartened by the number of people who still insist that LLMs are an expensive flop with no potential to meaningfully change software engineering.
In a few years, they'll be even better than they are now. They're already writing code that is perfectly decent, especially when someone is supervising and describing test cases.
Yea what? This is exactly why they should switch to native apps. Native apps are not harder to maintain than JavaScript especially with LLM guidance on APIs and such. I don't understand why your confidence in LLM code ability means you don't think it can succeed with native apps
No it is not the same with LLMs because LLMs are a multiplier that makes the overall work less compared to without them, and that includes support burden. "Support" is a hand wavy word to dismiss the fact that it consists of writing code and fixing bugs, all of which LLMs can help massively with now. They meaningfully change software engineering which you are ignoring when you assume the same cost of pre-LLM development on multiple platforms.
If without an LLM maintaining three apps is 3x the work and an LLM is a multiplier, then it's still 3x the work.
These are not magic. If you have to maintain consistency and security across three different apps written in three different stacks, you are still going to spent 3x the effort.
As for others, Microsoft is saying they’re porting all C/C++ code to Rust with a goal of 1m LOC per engineer per month. This would largely be done with AI.
Right, the biggest driver of global economic growth is not based on engineering at all, and these people (who've made massive amounts of money) clearly don't know how to describe the work they do.
How so? If coding is largely solved and we are on the cusp of not even needing to learn to code, then the statement that they use electron because it’s what most of their engineers are familiar with seems a little contradictory.
What's wrong with taking existing skills into consideration when making technical decisions while coding skills still matter, just because you think coding skills won't matter "in a year or two"? Where's the contradiction?
I would have expected the non-solved-cases to be the relatively unique ones, but considering the plethora of both A) non-Electron desktop apps, and B) coding agents (Copilot/Windsurf/Cursor/Codex/OpenCode/Qwen/Amazon Kiro/Devin/JetBrains AI/Gemini CLI/Gemini Code Assist/Antigravity/Warp/Kilocode/Cline/RooCode/Atlassian Rovo/Claude Code/etc), it seems like neither of the building blocks is very rare - perhaps Claude is just incapable of putting it together?
I'm guessing the first question will be "How are we going to keep the UI consistent?". The hard part is never the code writing it's carefully releasing fast changing features from product people. Their chat UX is the core product which is replicated on the internet and other devices. That's almost always React or [JS framework] these days.
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.
Yep, I understand why let's release this one feature everywhere is a great lure and I do get annoyed when desktop vs mobile spotify gets features later or never. However, a phone is not a desktop capability wise and what we usually get is the power of the phone on a desktop, aka the lowest common denominator of capabilities.
This fetish we as an industry have to hide platform specifics makes us blind to the platform specific capabilities. Some software would be better off if it leaned into the differences instead of fighting them.
But the question isnt really why claude is electron based. Its that if, for some reason, it had to be native on 3 platforms, could a swarm of agents make and maintain the 3 aps while all the humans did was make the spec and tests?
With your context and understanding of the coding agent's capabilities and limitations, especially Opus4.6, how do you see that going?
It is really confusing how we're told the last few years how all ourp rogrammers are obsolete and these billion dollar companies can't be arsed touse these magical tools to substantially improve their #1 user facing asset.
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:
Thanks for chiming in! My takeaways are that, as of today:
- 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
I think that comment is interesting as well. My view is that there is a lot of Electron training code, and that helps in many ways, both in terms of the app architecture, and the specifics of dealing with common problems. Any new architecture would have unknown and unforeseen issues, even for an LLM. The AIs are exceptional at doing stuff that they have been trained on, and even abstracting some of the lessons. The further you deviate away from a standard app, perhaps even a standard CRUD web app, the less the AI knows about how to structure the app.
Claude isn't AGI, but this is a terrible argument. I'm better at Javascript than C, too. Does this mean I'm not a generalized intelligence? I'm just JS stack autocomplete?
I suppose because generating tokens is slow. It is a limitation of the technology. And when data is coming in slowly, you don't need a super high performance client.
...I think a vibe-coded Cocoa app could absolutely be more performant than a run-of-the-mill Electron app. It probably wouldn't beat something heavily optimized like VS Code, but most Electron apps aren't like that.
Really? Because the point is that when it comes to performance, just implementing your own "DOM" in C++ or some other low level language is going to have 10x the performance of electron, easily, in addition to having more features (better, smoother, file uploads would be welcome btw).
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 ?
Somehow claude is only great at things that are surface level 80.9%
And for some reason i believe "may change in the future" will never come. we all know coding was never the problem in tech, hype was. ride it while you can
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!