Likewise OpenAIs browser is still only available on macOS, four months after launch, despite being built on a mature browser engine which already runs on everything under the sun. Seems like low-hanging fruit, and yet...
Probably has more to do with underwhelming adoption than anything else.
Why is Claude an Electron app?
271–280 of 483 posts
Re: Why is Claude an Electron app?
#272Earlier quoted context omitted.
Didn’t you say coding is a solved problem? So why are you still reaching for the lowest common denominator tech stack?
Did they say that? I doubt it.
Re: Why is Claude an Electron app?
#273Boris 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 keep being told by Anthropic and others than these AI coding tools make it effortless to write in new languages and port code from one language to another. This is an important lesson to watch what people do, not what they say.
Re: Why is Claude an Electron app?
#274This 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
We should repeat it over and over until all these electrons apps are replaced by proper native apps. It’s not just performance: they look like patched websites, have inconsistent style and bad usability, and packed with bugs that are already solved since tens of years in our OS. It’s like Active Desktop ™ all over. Working on a native Mac app feels just better.
You mean incongruent styles? As in, incongruent to the host OS.
There is no doubt electron apps allow the style to be consistent across platforms.
Re: Why is Claude an Electron app?
#275Earlier quoted context omitted.
Tell that to people abandoning Windows. (I'm writing this on a Linux machine right now) Most users are forced to use the software that they use. That doesn't mean they don't care, just that they're stuck. BTW, this going to matter MORE now that RAM prices are skyrocketing..
I'm not saying zero actual people care, I'm saying that not enough people care to actually differentiate. Is Windows getting better now that you switched? Then it doesn't matter you left.
https://www.techradar.com/computing/windows/microsoft-has-fi...
It seems like enough people do care to make Microsoft move.
Re: Why is Claude an Electron app?
#276Yes, feel free to downvote me.
Re: Why is Claude an Electron app?
#277You would think with programming becoming completely automated by the end of 2026, there'd be a vibe coded native port for every platform, but they must be holding back to keep us from all getting jealous.
Re: Why is Claude an Electron app?
#278Earlier quoted context omitted.
Did they say that? I doubt it.
https://m.youtube.com/watch?v=We7BZVKbCVw within the first few seconds.
Which is still quite the statement, and damn the video is intolerable. But the full quote still feels a little different than how you put it here.
Re: Why is Claude an Electron app?
#279Can we talk about how much copilot sucks in vscode? I have to use for work, buggy as hell for the premier product of a trillion dollar company.
Re: Why is Claude an Electron app?
#280Earlier quoted context omitted.
Only if they are supremely lazy. It’s possible to use these tools in a diligent way, where you maintain understanding and control of the system but outsource the implementation of tasks to the LLM. An engineer should be code reviewing every line written by an LLM, in the same way that every line is normally code reviewed when written by a human. Maybe this changes the original argument from software being “free”, but…
> An engineer should be code reviewing every line written by an LLM, I disagree. Instead, a human should be reviewing the LLM generated unit tests to ensure that they test for the right thing. Beyond that, YOLO. If your architecture makes testing hard build a better one. If your tests arent good enough make the AI write better ones.
If you did, the tests would be at least as complicated as the code (almost certainly much more so), so looking at the tests isn’t meaningfully easier than looking at the code.
If you didn’t, any functionality you didn’t test is subject to change every time the AI does any work at all.
As long as AIs are either non-deterministic or chaotic (suffer from prompt instability, the code is the spec. Non determinism is probably solvable, but prompt instability is a much harder problem.