Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why is Claude an Electron app?

dbreunig.com

Post reply on HN
Print view View original

331–340 of 483 posts

Re: Why is Claude an Electron app?

#331

Post by rustystump »

selridge wrote: post #147
rustystump wrote: post #125

Earlier quoted context omitted.

Bun exists and building a ui on too of that should be well within the power of the money they have. No one is saying to rebuild the universe but the current state is embarrassing.

Yeah but what does the statement refute? We can all talk about how this or that app should be different, but the idea is "electron sux => ????? " Why should I care that they didn't rebuild the desktop app I don't use. Their TUI is really nice.

You could build the same tui in the same amount of time with the same effort and end with an overall better product. Spend a little more and it is even better. Why can we not expect more from companies that have more?

Re: Why is Claude an Electron app?

#332

Post by ses1984 »

ajross wrote: post #199
hedgehog wrote: post #180

Earlier quoted context omitted.

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)

> 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 candi…

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.

Re: Why is Claude an Electron app?

#333

Post by JuniperMesos »

ajross wrote: post #199
hedgehog wrote: post #180

Earlier quoted context omitted.

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)

> 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 candi…

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.

Re: Why is Claude an Electron app?

#334

Post by phist_mcgee »

sarchertech wrote: post #321
felixrieseberg wrote: post #293

Hi, Felix here - I'm responsible for said Electron app, including Claude Code Desktop and Claude Cowork. 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:…

Let’s ignore electron. Your app has many UI/UX and performance flaws. 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?

What kind of project lead is going to answer for their CEO?

Re: Why is Claude an Electron app?

#335

Post by reitzensteinm »

xyzsparetimexyz wrote: post #281
reitzensteinm wrote: post #227

Earlier quoted context omitted.

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 wa…

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

The field will spread. I'm working on what I'm intending up be the best game of my career, but you can ship barely functional slop in a few days.

Re: Why is Claude an Electron app?

#336

Post by reitzensteinm »

dizhn wrote: post #322
reitzensteinm wrote: post #227

Earlier quoted context omitted.

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 wa…

Don't the cli panes flicker like crazy?

No, they're generally pretty solid. Once an hour one will crash, and sometimes there are performance problems, but it's a very workable setup.

Re: Why is Claude an Electron app?

#337

Post by wtetzner »

tom1337 wrote: post #166

I don't care wether its electron or not but the now ship a full vm with Claude which not only takes 15 GB of storage but also uses so much memory even though I just use chat. Why does that even need to be started?

Especially now that they've made RAM so expensive.

Re: Why is Claude an Electron app?

#338

Post by internet2000 »

hedgehog wrote: post #180
bcherny wrote: post #149

Boris from the Claude Code team here. 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)

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!

Re: Why is Claude an Electron app?

#339

Post by cloverich »

danpalmer wrote: post #128
torginus wrote: post #66

Earlier quoted context omitted.

I don't know why anyone uses Tauri - disk space is cheap but having to handle QA and supporting quirks for every possible browser engine the users' system could ship with certainly is not.

It's a RAM issue not a disk space issue. Binaries get loaded into memory. Also if you haven't heard, disk space is no longer as cheap, and RAM is becoming astoundingly expensive.

My Native macos app was using well over 1gb the other day, while my electron notes app was 1/5 of it. Theres an electron tax for sure but people are wildy mixing up application architecture issues and bugs with the framework tax.

Re: Why is Claude an Electron app?

#340

Post by mapontosevenths »

sarchertech wrote: post #325
mapontosevenths wrote: post #305

Earlier quoted context omitted.

> As long as AIs are either non-deterministic or chaotic You just hit the nail on the head. LLM's are stochastic. We want deterministic code. The way you do that is with is by bolting on deterministic linting, unit tests, AST pattern checks, etc. You can transform it into a deterministic system by validating and constraining output. One day we will look back on the days before we validated output the same way we now…

None of those things make it deterministic though. And they certainly don’t make it non-chaotic. You can have all the validation, linters, and unit tests you want and a one word change to your prompt will produce a program that is 90%+ different. You could theoretically test every single possible thing that an outside observer could observe, and the code being different wouldn’t matter, but then your tests would be 1…

> None of those things make it deterministic though.

In the information theoretical sense you're correct, of course. I mean it's a variation on the halting problem so there will never be any guarantee of bug free code. Heck, the same is true of human code and it's foibles. However, in the "does it work or not" sense I'm not sure why we care?

If the gate only passes the digits 0-9 sent within 'x' seconds, and the code's job is to send a digit between 0 and 9, how is it non-deterministic?

Let's say the linter says it's good, it passes the regression tests, you've validated that it only outputs what it's supposed to and does it in a reasonable amount of time, and maybe you're even super paranoid so you ran it through some mutation tests just to be sure that invalid inputs didn't lead to unacceptable outputs. How can it really be non-deterministic after all that? I get that it could still be doing some 'other stuff' in the background, or doing it inefficiently, but if we care about that we just add more tests for that.

I suppose there's the impossible problem edge case. IE - You might never get an answer that works, and satisfies all constraints. It's happened to me with vibe-coding several times and once resulted in the agent tearing up my codebase, so I learned to include an escape hatch for when it's stuck between constraints ("email user123@corpo.com if stuck for 'x' turns then halt"). Now it just emails me and waits for further instruction.

To me, perfect is the enemy of good and good is mostly good enough.

Post reply on HN