Claude is an Electron App because we've lost native

Source: Hacker News

Claude is an Electron App because we’ve lost native

In “Why is Claude an Electron App?” Drew Breunig wonders:

Claude spent $20 k on an agent swarm implementing (kinda) a C‑compiler in Rust, but desktop Claude is an Electron app.
If code is free, why aren’t all apps native?

He then argues that the answer is that LLMs are not good enough yet. They can do 90 % of the work, so there’s still a substantial amount of manual polish, and thus increased costs.

But I think that’s not the real reason. The real reason is: native has nothing to offer.

API landscape

Native APIs lost to web APIs a long time ago. Native APIs are often cumbersome, and OS vendors frequently make it unattractive to develop native apps for their platforms. This explains the rise of Electron before the LLM era, and it’s also a problem that LLMs solve now: if the barrier to developing native apps was real, it no longer exists.

Looks and consistency

In the late 1990s and 2000s, native applications were ahead in terms of visual quality and consistency. The more apps used a native look and feel, the better the overall user experience.

Today, native is as inconsistent as the web, if not worse. Buttons lack borders, contrast is missing, and conventions have eroded. Apple, for example, seems to place traffic‑lights and corner radii by “vibes” rather than measurable guidelines.

Maybe the server should round the corners?

Looks can be good, but they can also be bad, leaving you stuck with platform‑consistent yet generally poor UI (think “Liquid Glass”). UI guidelines change frequently; an app that looks appropriate today may look out of place next year when Apple updates its design language. There is no longer a distinct “native look”.

Computer UIs also degrade over time

Integration depth

Theoretically, native apps can integrate more deeply with the OS. In practice, this advantage is limited: interoperable file formats are scarce, most services have moved to the web, and OSes have not provided a solid shared baseline. You can integrate with an OS‑provided calendar, but doing the same on the web is often easier. Native integration does not inherently solve these problems.

Web pages only lead to more web pages

Performance expectations

Performance is often cited as the last hope for native. While native apps can be faster, they are not guaranteed to be. Web apps can also achieve high performance, and in practice, most users don’t notice the difference. There’s no technical reason why Slack needs to load 80 MiB just to show a few channel names and messages. The web isn’t the problem; it’s a choice to be inefficient. Switching to native does not automatically resolve that.

Closing thoughts

Writing this brings me no joy, and I don’t think the web is a perfect solution either. I remember a time when native did a better‑than‑average job, and we all benefited from it. It saddens me that those times have passed.

Kidding ourselves that the only problem with software is Electron, and that everything will be “butterflies and unicorns” once we rewrite Slack in SwiftUI, is unproductive. The real problem is a lack of care—and sloppiness; you can build a bad product with any stack.