Claude is an Electron App because we've lost native

ttd

Some random thoughts, since I've had a similar train of thought for a while now. On one hand I also lament the amount of hardware-potential wastage that occurs with deep stacks of abstractions. On the other hand, I've evolved my perspective into feeling that the medium doesn't really matter as much as the result... and most software is about achieving a result. I still take personal joy in writing what I think is well-crafted code, and I also accept that that may become more niche as time goes on. To me this shift from software-as-craft to software-as-bulk-product has some similarities to the "pets vs cattle" mindset change when thinking about server / process orchestration and provisioning. Then also on the dismay of JS becoming even more entrenched as the lingua franca. There's every possibility that in a software-as-bulk-product world, LLM-driven development could land on a safer language due to efficiency gains from e.g. static type checking. Economically I wonder if an adoption of a different lingua franca could manifest by way of increasing LLM development speed / throughput.

mushufasa

Perhaps a hot take, but I'm glad for electron apps because that also means they will be well supported on linux, which is almost never the target of native development.

drcongo

I really hate Electron, but something is so rotten under macOS that even some of Apple's own native apps are appalling. The Settings and Passwords apps are so bad as to be almost unusable, I'd love to know how and why they're that bad - are they catalyst, or just badly made?

goda90

Maybe the hardware supply crisis caused by demand for AI data centers will lead to a push for more efficient and backwards compatible client software.

pjmlp

Nah, some developers are lazy, that is all, lets not dance around the bush with that one. Most of those Electron folks would not manage to even write C applications on an Amiga, use Delphi, VB, or whatever. Educated on node and do not know anything else. Even doing a TUI seems like a revelation to current generations, something quite mudane and quite common on 1980's text based computing of Turbo Vision, Clipper and curses.

lapcat

It's weird for the author to mention Mac window buttons and corner radius as reasons to use Electron, because while the main content of Electron app windows is HTML, the Electron windows themselves and the window chrome are native, with the same buttons and corner radius as other apps on the system. Electron is a native wrapper for web content. The wrapper is still native. > Native APIs are terrible to use, and OS vendors use everything in their power to make you not want to develop native apps for their platform. I'm honestly not quite sure what the author means here. Web APIs are equally “terrible” in my opinion. In any case, you have to release an Electron app on Mac the same way you release any native app on Mac. The benefit of using web APIs is not that they are non-terrible but that you can share the same code as your website. And of course you can more easily find web developers than native developers. But that has nothing to do with whether or not the API is terrible. It’s just supply and demand. I’ll take AppKit and autolayout any day over CSS, ugh. CSS is the worst.

reconnecting

10 days ago: https://news.ycombinator.com/item?id=47104973

rapnie

Besides going full native, a Tauri [0] app might have been another good alternative given they already use Rust. There are pros and cons to that choice, of course, and perhaps Tauri was considered and not chosen. Tauri plus Extism [1] would have been interesting, enabling polyglot plugin development via wasm. For Extism see also the list of known implementations [2]. [0] https://tauri.app/ [1] https://extism.org/ [2] https://github.com/extism/extism/discussions/684

nitwit005

Even if web rendering is the best technology possible, there's still plenty you could hypothetically optimize, like replacing the Javascript with native code, or cutting out unused features to get a smaller download. Ultimately, Claude having limitations is an issue. They can't just point it at the code base and ask it to make it faster.

zitterbewegung

X foundational model Apps UIs are electron apps because all of them are web first and App second and the easiest way to do this is being an Electron app.

daxfohl

I imagine the first step would be for them to make a cross platform UI framework that's better than any existing options, and then port claude to it. Making five different apps just to claim "native" doesn't seem like a great choice, and obviously for now, delivering new claude features takes priority over a native graphics framework, so electron makes sense. But that doesn't mean it'll be on electron forever.

asah

great post - let me add that native was forced into some of this by the web: 1. locked up files ==> that's for security, which wasn't an issue in the 1990s. 2. inconsistent look ==> people are embedding browsers inside apps for all sorts of reasons, ruining the "native" UI/UX even if the OS "look" were stable. It took a while, but once again open source and the web kinda won, though if you like consistency, then I agree it's a pyrrhic victory...

rvz

More like a skill issue, than 'losing native'.

fHr

Codex cli rust /thread

baggachipz

Clicks link, goes to blog site My eyes! The goggles, they do nothing!

1970-01-01

Isn't native just the CLI?

giancarlostoro

I have been using Claude Code ironically enough to build native apps via Qt and Rust, the output is impressive. Might give writing an IRC client a shot and put it in GitHub.

andyjohnson0

I felt that this article didn't provide strong justifications for some of its assertions. > Native APIs are terrible to use, and OS vendors use everything in their power to make you not want to develop native apps for their platform. Disagree. I'm most familiar with Windows and Android - but native apps on those platforms, snd also on Mac, look pretty good when using the default tools and libraries. Yes, its possible to use (say) material design and other ux-overkill approaches on native, but thats a choice just like it us for web apps. And OS vendors are very much incentivised to make natuve development as easy and painless as possible - because lock-in. > That explains the rise of Electron before LLM times, Disagree. The "rise of Electron" is due to the economics of skill-set convergence on JS, the ubiquity of the JS/HTML/CSS/Node stack platform, and many junior developers knowing little or nothing else. As for the rest: minor variations in traffic light positioning and corner radii are topical but hardly indicators of decaying platorms.

d0m

Apple/Google could easily make web apps native if they wanted

etothet

"The real reason is: native has nothing to offer." I get it, but this is a bit dramatic. One of the biggest challenges I've found with using non-native tools (and specifically the various frameworks that let you write JavaScript that compile to Native code) is that there is much less of a guarantee that the 3rd party solution will continue support for new OS versions. There's much less of a risk with that with 1st party solutions. Additionally, those 3rd parties are always chasing the 1st part vendor for features. Being far behind the regular cadence of releases can be quite inconvenient, despite any advantages initially gained.