Live data from Hacker News

Why is Claude an Electron app?

dbreunig.com

171–180 of 483 posts

Re: Why is Claude an Electron app?

#171

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!

[deleted]

Re: Why is Claude an Electron app?

#172

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.

I'm pretty sure Tauri uses almost as much RAM, you just don't see it because it gets assigned to some kind of system process associated with the webview. Most of the RAM used by a browser is per-tab.

Re: Why is Claude an Electron app?

#174

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!

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

Re: Why is Claude an Electron app?

#175

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!

Couldn't this have been vibe coded into a native app that is more performant?

Re: Why is Claude an Electron app?

#176

I don't know why anyone uses Electron anymore, Tauri produces much smaller binaries and is amazing.

Agreed! I built a MacOS Postgres client with just Claude Code[1]. It could use some UI improvements, but it runs much better than other apps I’ve tried (specifically what it’s replacing for me: RazorSQL) and the binary is smaller than 20MB. 1: https://github.com/NeodymiumPhish/Pharos

It's not free, but Postico is excellent https://eggerapps.at/postico2

Re: Why is Claude an Electron app?

#177

Earlier quoted context omitted.

And after 12 months, most probably no one from your team will understand what the result of half of those bugs is. When devs outsource their thinking to AI, they lose the mental map, and without it, control over the entire system.

I find this such a weird stance to take. Every system I work on and bug I fix has broad sets of code that I didn't write in it. Often I didn't write any of the code I am debugging. You have to be able to build a mental map as you go even without ai.

When you work on a pre-existing codebase, you don't understand the code yet, but presumably somebody understood parts of it while building it. When you use AI to generate code, you guarantee that no one has ever understood the code being summoned. Don't ignore this difference.

Re: Why is Claude an Electron app?

#178

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!

The second you wanted to add a webview, you want Electron. Devs want Chrome DevTools and Chrome runtime.

You guys just did add it too, so yeah!

Re: Why is Claude an Electron app?

#179
post #175

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!

Couldn't this have been vibe coded into a native app that is more performant?

> vibe coded

> more performant

I found the problem.

Re: Why is Claude an Electron app?

#180

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)
Post reply on HN