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 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'm currently building a macOS AI chat app. Generally SwiftUI/AppKit is far better than Web but it performs bad in few areas. One of them is Markdown viewer. Swift Markdown libraries are slow and lacks some features like Mermaid diagrams. To work around this, some of my competitors use Tauri/Electron and few others use WKWebView inside Swift app.

Initially I tried WKWebView. Performance was fine and the bridge between JS and Swift was not that hard to implement but I started seeing few problems especially due to the fact that WebView runs as separate process and usually a single WebView instance is reused across views.

After few attempts to fix them, I gave up the idea and tempted to go fully with Web rendering with Tauri but as a mac developer I couldn't think about building this app in React. So I started building my own Markdown library. After a month of work, I now have a high-performance Markdown library built with Rust and TextKit. It supports streaming and Markdown extensions like Mermaid.

Most of the code was written by Claude Opus, and some tricky parts were solved by Codex. The important lesson I learned is that I’m no longer going to accept limitations in tech and stop there. If something isn’t available in Swift but is available in JS, I’m going to port it. It’s surprisingly doable with Claude.

Edit: The title of the post originally started with "If code is free,"

- 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

It's pretty easy to argue your point if you pick a strawman as your opponent.

They have said that you can be significantly more productive (which seems to be the case for many) and that most of their company primarily uses LLM to write code and no longer write it by hand. They also seems to be doing well w.r.t. competition.

There are legitimate complaints to be made against LLMs, pick one of them - but don't make up things to argue against.

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.

I've been building a native macOS/iOS app that lets me manage my agents. Both the ability to actually control/chat fully from the app and to just monitor your existing CLI sessions (and/or take 'em over in the app).

Terrible little demo as I work on it right now w/claude: https://i.imgur.com/ght1g3t.mp4

iOS app w/codex: https://i.imgur.com/YNhlu4q.mp4

Also has a rust server that backs it so I can throw it anywhere (container, pi, etc) and the connect to it. If anyone wants to see it, but I have seen like 4 other people at least doing something similar: https://github.com/Robdel12/OrbitDock

Claude is going to help mostly with code, much less with design. It might help to accelerate integration, if the application is simple enough and the environment is good enough. The fact is, going cross-platform native trebles effort in areas that Claude does not yet have a useful impact.

Also AI is better at beaten path coding. Spend more tokens on native or spend them on marketing?

Computers have gotten orders of magnitude faster since 2016, but using mainstream apps certainly don't feel any faster. Electron and similar frameworks do offer appealing engineering tradeoffs, but they are a main culprit of this problem.

Sure, the magnitude of RAM/compute "waste" may have grown from kB to MB, but inefficiency is still inefficiency - no matter how powerful the machine it's running on is.

If only AI had more Liquid Glass, lol

I hope that prevalence of AI coding agents might lead to a bit of a revival of RAD tools like lazarus, which seem to me to have a good model for creating cross-platform apps.

Then what?

Not saying I'm not using AI - because I am. I'm using it in the IDE so I can stay close to every update and understand why it's there, and disagree with it if it shouldn't be there. I'm scared to be distanced from the code I'm supposed to be familiar with. So I use the AI to give me superpowers but not to completely do my job for me.

We should refuse to accept coding agents until they have fully replaced chromium. By that point, the world will see that our reticence was wisdom.

You're easy to impress, that explains the unrealistic expectations "on the surface". That's some strange analogy, though, basic usability is the first mile, not the last. Coming back to the frameworks and apps, the last mile would be respecting Mac unique keyboard bindings file for text editing. First mile is reacting to any keyboard input in a text field. Same with the compiler, basic hello world fail isn't the last mile.

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

I only see these complaints on HN. Real users don't have this complaint. What kind of low-end machines are you running, that Chromium engine is too heavy for you?

> They are often laggy or unresponsive.

That's not due to Electron.

> They don’t integrate well with OS features.

If it is good enough for Microsoft Teams it is probably good enough for most apps. Teams can integrate with microphone, camera, clipboard, file system and so on. What else do you want to integrate with?

A native app is the wrong abstraction for many desktop apps. The complexity of maintaining several separate codebases likely isn't worth the value add. Especially for a company hemorrhaging money the way the Anthropic does.

I've been building a native macOS AI client in Swift — it's 15MB, provider-agnostic, and open source: https://github.com/dinoki-ai/osaurus

Committing to one platform well beats a mediocre Electron wrapper on all three.

A few years ago maybe. Tauri makes better sense for this use case today - like Electron but with system webviews, so at least doesn't bloat your system with extra copies of Chrome. And strongly encourages Rust for the application core over JS/Node.

It's a nodejs app, and there is no reason to have a problem with that. Nodejs can wait for inference as fast as any native app can.

It is easy to crank out a one-off, flashy tool using Claude (to demo its capabilities), which may tick 80% of the development work.

If you've to maintain it, improve, grow for the long haul, good luck with it. That's the 20% hard.

They took the safe bet!

You just have to be really careful because the agent can easily slip into JS hell; it has no shortage of that in its training.

The fact that claude code is a still buggy mess is a testament to the quality of the dream they're trying to sell.

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

And despite what Anthropic and OpenAI want you to think, these LLMs are not AGI. They cannot invent something new. They are only as good as the training data.

Yes, feel free to downvote me.

nailing down all the edge cases