Live data from Hacker News

Why is Claude an Electron app?

dbreunig.com

291–300 of 483 posts

Re: Why is Claude an Electron app?

#291
post #87

This post and this entire thread are HN-sniping to the millionth degree. We have all the classics here: - 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

Author of the post here.

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.

Re: Why is Claude an Electron app?

#292

Because code isn't free. 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.

I love the fact that we just got a model really capable of doing sustained coding (let me check my notes here...) 3 months ago, with a significant bump 15 days ago. And now the comments are "If it is so great why isn't everything already written from scratch with it?"

People are getting caught up in the "fast (but slow) diffusion)" that Dario has spoken to. Adoption of these tools has been fast but not instant but people will poke holes via "well, it hasn't done x yet".

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

Re: Why is Claude an Electron app?

#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: 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.

Re: Why is Claude an Electron app?

#296

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!

I thought coding was already solved by Claude? Why aren't you vibe coding something that isn't dogshit with your fancy little Code Solver?

Re: Why is Claude an Electron app?

#297
post #199

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…

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

Re: Why is Claude an Electron app?

#298
post #249

Because it's the most popular & flexible cross platform user space compositor: - 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).

Qt is LGPL, so free for commercial use in most situations.

There are rules when using the lgpl version of qt, the kde foundation has an exception I think.

https://www.qt.io/development/open-source-lgpl-obligations

Re: Why is Claude an Electron app?

#299
post #247
post #199

Earlier quoted context omitted.

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

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.

> 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.

It's over, sorry.

Re: Why is Claude an Electron app?

#300
post #81

Here is what worries me the most at the moment: we're in a period of hype, fire all the developers, we have agents, everybody can code now, barrier is not low - it's gone. Great. Roll up a year from now, and we have trillions of lines of code no human wrote. At some point, like a big PR, the agent's driver will just say yes to every change. Nobody now can understand the code easily because nobody wrote it. It works,…

I think the idea is that by the time those trillions of lines of code start to cause maintenance problems, the models will be good enough to deal with those problems.

We'll see, I guess...

Post reply on HN