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.
