[hedgehog]

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)

[reitzensteinm]

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.

[xyzsparetimexyz]

God the number of ghastly survival crafting LLM slop games that are gonna appear on steam 6 months from now...

[dizhn]

Don't the cli panes flicker like crazy?

[IAmGraydon]

What have you shipped so far?

[gukov]

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.

[blibble]

> You'd think these apps be a shining example of what's possible.

it is

[fakedang]

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.

[internet2000]

As a user, I wouldn't. I can deal with the jank. Keeping up to domain when the domain is evolving THIS fast is important!

[cyanydeez]

Thats probably the janky react, not electron.

[ajross]

> a UI that doesn't jank and max out the CPU

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.

[JuniperMesos]

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.

[pjmlp]

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.

[clipsy]

You might try giving an example of a complex UI that isn't a frustratingly slow resource hog next time you're posting this rant.

[kadoban]

> While there are legitimate/measurable performance and resource issues to discuss regarding Electron, this kind of hyperbole just doesn't help.

From the person you're responding to:

> I would guess a moderate amount of performance engineering effort could solve the problem without switching stacks or a major rewrite.

Pretty clearly they're not saying that this is a necessary property of Electron.

[ses1984]

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.

[cgh]

You think VSCode’s ui is more complicated than eg Microsoft Excel? Or am I misunderstanding?

[hedgehog]

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.