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 tried the desktop app and was shocked at the performance. Conversations would take a full second to load, making rapidly switching intolerable. Kicking off a new task seems to hang for multiple seconds while I'm assuming the process spins up.

I wanted to try a disposable conversations per feature with git worktree integration workflow for an hour to see how it contrasted, but couldn't even make it ten minutes without bailing back to the terminal.

The more content is available, the more curation is important and IMO their algorithm currently does a good job at it.

Steam kept pushing a game as "recommended for you" with 99% negative reviews.

In what world would I possibly want to buy a game with a <1% approval rating?

> pretty solid

Huh?

it is

While there are legitimate/measurable performance and resource issues to discuss regarding Electron, this kind of hyperbole just doesn't help.

I mean, look: the most complicated, stateful and involved UIs most of the people commenting in this thread are going to use (are going to ever use, likey) are web stack apps. I'll name some obvious ones, though there are other candidates. In order of increasing complexity:

1. Gmail

2. VSCode

3. www.amazon.com (this one is just shockingly big if you think about it)

If your client machine can handle those (and obviously all client machines can handle those), it's not going to sweat over a comparatively simple Electron app for talking to an LLM.

Basically: the war is over, folks. HTML won. And with the advent of AI and the sunsetting of complicated single-user apps, it's time to pack up the equipment and move on to the next fight.

From the person you're responding to:

> I would guess a moderate amount of performance engineering effort could solve the problem without switching stacks or a major rewrite.

Pretty clearly they're not saying that this is a necessary property of Electron.

Maybe you can give ones of competing ones of comparable complexity that are clearly better?

Again, I'm just making a point from existence proof. VSCode wiped the floor with competing IDEs. GMail pushed its whole industry to near extinction, and (again, just to call this out explicitly) Amazon has shipped what I genuinely believe to be the single most complicated unified user experience in human history and made it run on literally everything.

People can yell and downvote all they want, but I just don't see it changing anything. Native app development is just dead. There really are only two major exceptions:

1. Gaming. Because the platform vendors (NVIDIA and Microsoft) don't expose the needed hardware APIs in a portable sense, mostly deliberately.

2. iOS. Because the platform vendor expressly and explicitly disallows unapproved web technologies, very deliberately, in a transparent attempt to avoid exactly the extinction I'm citing above.

It's over, sorry.

Thunderbird is a fully-featured mail app and much more performant than Gmail. Neovim has more or less the same feature set as VSCode and its performance is incomparably better.

TB is great and I use it every day. An argument for it from a performance standpoint is ridiculous on its face. Put 10G of mail in the Inbox and come back to me with measurements. GMail laughs at mere gigabytes.

Using market success to excuse poor UX is pointless.

OK, I shop at Amazon, am a Prime member, all that stuff, but their web site is horrible. Just pathetic.

I appreciate that they are huge and sell a pretty much incomprehensible number of things, and that what it takes behind the scenes to make it all happen is hugely complex and very impressive on its own terms, but still: the web site is horrible.

Try enabling 10k lines of scrollback buffer in vscode and print 20k lines.

In any case, what I personally find more problematic than just slowness is electron apps interacting weirdly with my Nvidia linux graphics drivers, in such a way that it causes the app to display nothing or display weird artifacts or crash with hard-to-debug error messages. It's possible that this is actually Nvidia's fault for having shitty drivers, I'm not sure; but in any case I definitely notice it more often with electron apps than native ones.

Anyway one of the things I hope that AI can do is make it easier for people to write apps that use the native graphics stack instead of electron.

Sigh. Beyond the deeply unserious hyperbole, this is a no-true-scotsman. Yes, you can use native APIs in Electron. They can even help. That's not remotely an argument for not using Electron.

> the in-editor terminal makes use of WebGL

Right, because clearly the Electron-provided browser environment was insufficient and needed to be escaped by using... a browser API instead?

Again, folks, the argument here is from existence. If the browser stack is insufficient for developing UIs in the modern world, then why is it winning so terrifyingly?

Gen X and Boomers strangely enough managed to write portable native code, across multiple hardware architectures, operating systems and language toolchains.

As is an insurmountable challenge apparently, to master Web UI delivery from system services, daemons to the default browser like UNIX administration tooling.

If McDonald’s hamburgers taste like warmed-over shit, why are they the most popular in the world?

Setting that aside, I think you learned the wrong lesson here. There's no fight. Performance comes from app architecture engineering more than the underlying tools. Building on the trash fire that is the current JS ecosystem may make it harder, true, but apps like VS Code, Discord, Slack, etc show that with enough effort a team can use those tools to deliver something with relatively much better performance. The underlying browser engines are quite sophisticated and very efficient for what they are asked to do, it's just a question of good engineering on top of that. Based on the observable behavior I'm guessing the Claude app is doing something like triggering reflow for the entire chat thread every time they append a few characters to the chat. Totally avoidable.

The big reason web tech is ubiquitous is it has the best properties for distribution. That may last a little while or a long time, but there is no fundamental reason why it's more durable than say Win32 and MFC.

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.

https://www.lennysnewsletter.com/p/head-of-claude-code-what-...

This is an important lesson to watch what people do, not what they say.

Surely, it would be a flex to show that your AI agents are so good they make electron redundant.

But they don’t. So it’s reasonable to ask why that is.

2. Why do you think it requires "three times the resources" - wouldn't it normally be an incremental amount of work to support additional targets, but not an additional 100% of work for each additional target?

Because then their competition would work faster than they could and any amount of slop/issues/imperfections would be amplified threefold.

Also there would inevitably be some feature drift - I got SourceTree for my Mac and was surprised to discover that it's actually somewhat different from the Windows version, that was a bit jarring.

I hope that in the next decade we get something like lcl (https://en.wikipedia.org/wiki/Lazarus_Component_Library), but for all OSes and with bindings for all common languages - so we don't have to rely on the web platform for local software, until then developing native apps is a hard sell.

In a few years, they'll be even better than they are now. They're already writing code that is perfectly decent, especially when someone is supervising and describing test cases.

These are not magic. If you have to maintain consistency and security across three different apps written in three different stacks, you are still going to spent 3x the effort.

Given the choice, I often reach for Electron apps because they feel more feature rich, feel better designed in terms of polish (both UI and UX), and I rarely get resource hog issues (Slack is the only offender I can think of among the Electron apps I use)

Also, keep in mind that many people would like their applications to respect their preferences, so the "polish" that looks completely out of place on their screen is ugly (besides slow).

you should read this - all three parts, very educational (though with 30 years as “engineer” I don’t agree with it all but it is very educational, especially part 1): https://www.hillelwayne.com/post/are-we-really-engineers/

https://www.lennysnewsletter.com/p/head-of-claude-code-what-...

As for others, Microsoft is saying they’re porting all C/C++ code to Rust with a goal of 1m LOC per engineer per month. This would largely be done with AI.

https://www.thurrott.com/dev/330980/microsoft-to-replace-all...

If coding is a solved problem and there is no need to write code, does the language really matter at that point?

If 1 engineer can handle 1m LOC per month, how big would these desktop apps be where maintaining native code becomes a problem?

if that's the case, why don't you just ask it to "make it not shit"?

With your context and understanding of the coding agent's capabilities and limitations, especially Opus4.6, how do you see that going?

Huh?

The sheer speedup all users will show everyone why vibe coding is the future. After all coding is a solved problem.

Migrating the system would be the easier part in that regard, but they'll still need a JS UI unless they develop multiple teams to spearhead various native GUIs (which is always an option).

Almost every AI chat framework/SDK I've seen is some React or JS stuff. Or even agent stuff like llamaindex.ts. I have a feeling AI is going to reinforce React more than ever.

This fetish we as an industry have to hide platform specifics makes us blind to the platform specific capabilities. Some software would be better off if it leaned into the differences instead of fighting them.

It's the fastest way to iterate because Electron is the best cross platform option and because LLMs are likely trained on a lot of HTML/Javascript.

Which is why Claude is great at it.

- 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

Could you visualize the user's usage? For example, like a glass of water that is getting emptier the more tokens are used, and gets refilled slowly.

Because right now I have no clue when I will run out of credits.

Thanks!

You guys just did add it too, so yeah!

I'm glad to see this coming from a company that is so popular these days.

Thanks!

So the model is not a generalised AI then? It is just a JS stack autocomplete?

> more performant

I found the problem.

But it should be possible to make an Electron app that is more reliable and eats less resources.

Why does it matter what tech the engineers used in the past? I thought they didn't write code anymore.

I always wonder how those established Electron codebases would map over to something that uses the system specific WebViews and how broken (or not) those would prove to be:

https://wails.io

https://tauri.app

But admittedly that would just decrease the bundle size while doing not much for the performance or resource usage: https://github.com/Elanis/web-to-desktop-framework-compariso... so maybe not super relevant to this particular discussion.

If you can put in unlimited coding engineering effort, why isn't Claude Code the very best it can possibly be?

Why isn't the fact that it can work 10% better an excuse to get claude to work on it for however long it takes?

I mean, most people here have done development with claude code, and we suppose the answer is simply: because that doesn't work without a capable engineer constantly babysitting the changes it's making, guiding it, nudging it, reminding it about edge cases, occasionally telling it it's being stupid ... it's a great product, incredible even, but it doesn't work without senior engineers.

Same question: Why doesn't it have more plugins and batch script and modfications than the app store? Surely it can by itself come up with 10000 good ideas and just implement them? Everything from little games to how to active bedroom lights by chinese vendor #123891791 ?

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.

When devs outsource their thinking to AI, they lose the mental map, and without it, control over the entire system.

But I don’t get how they code in Anthropic when they say that almost all their new code is written by LLM.

Do they have some internal much smarter model that they keep in secret and don’t sell it to customers? :)

Kepping in mind they are trying hard to sell their code assistant what else they can say?

Goal is simple: just lie your way forward to the next VC funding round.

When is the last time you had an on call blow up that was actually your code?

Not that I’m some savant of code writing — but for me, pretty much never. It’s always something I’ve never touched that blows up on my Saturday night when I’m on call. Turns out it doesn’t really change much if it’s Sam who wrote it … or Claude.

Remember, they're not just good for writing code. They're amazing at reading code and explaining to you how the architecture works, the main design decisions, how the files fit together, etc.

It means Sam is 7 beers deep on Saturday night since you’re the one on call. He’s not responding to your slack messages.

Claude actually is there though, so that’s kind of nice.

Claude is there as long as you're paying,and I hope he doesn't hallucinate an answer.

Emphasis mine.

> Claude is there as long as you're paying

If you’re at a company that doesn’t pay for AI in the year 2026, you should find a new company.

> and I hope he doesn't hallucinate an answer.

Unlike human coworkers with a 100% success rate, naturally.

There is a difference between a lector and an author

In sufficiently complicated systems, the 10xer who knows nothing about the edge cases of state could do a lot more damage than an okay developer who knows all the gotchas. That's why someone departing a project is such a huge blow.

It’s a difference reading code if you’re are also a writer of than purely a reader.

It’s like only reading/listening to foreign language without ever writing/speaking it.

Use AI as a sanity check on your thinking. Use it to search for bugs. Use it to fill in the holes in your knowledge. Use it to automate grunt work, free your mind and increase your focus.

There are so many ways that AI can be beneficial while staying in full control.

I went through an experimental period of using Claude for everything. It's fun but ultimately the code it generates is garbage. I'm back to hand writing 90% of code (not including autocomplete).

You can still find effective ways to use this technology while keeping in mind its limitations.

It’s easy to see the immediate speed boost, it’s much harder to see how much worse maintaining this code will be over time.

What happens when everyone in a meeting about implementing a feature has to say “I don’t know we need to consult CC”. That has a negative impact on planning and coordination.

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 we could just change that to mean “super cheap”.

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.

You just hit the nail on the head.

LLM's are stochastic. We want deterministic code. The way you do that is with is by bolting on deterministic linting, unit tests, AST pattern checks, etc. You can transform it into a deterministic system by validating and constraining output.

One day we will look back on the days before we validated output the same way we now look at ancient code that didn't validate input.

You can have all the validation, linters, and unit tests you want and a one word change to your prompt will produce a program that is 90%+ different.

You could theoretically test every single possible thing that an outside observer could observe, and the code being different wouldn’t matter, but then your tests would be 100x longer than the code.

In the information theoretical sense you're correct, of course. I mean it's a variation on the halting problem so there will never be any guarantee of bug free code. Heck, the same is true of human code and it's foibles. However, in the "does it work or not" sense I'm not sure why we care?

If the gate only passes the digits 0-9 sent within 'x' seconds, and the code's job is to send a digit between 0 and 9, how is it non-deterministic?

Let's say the linter says it's good, it passes the regression tests, you've validated that it only outputs what it's supposed to and does it in a reasonable amount of time, and maybe you're even super paranoid so you ran it through some mutation tests just to be sure that invalid inputs didn't lead to unacceptable outputs. How can it really be non-deterministic after all that? I get that it could still be doing some 'other stuff' in the background, or doing it inefficiently, but if we care about that we just add more tests for that.

I suppose there's the impossible problem edge case. IE - You might never get an answer that works, and satisfies all constraints. It's happened to me with vibe-coding several times and once resulted in the agent tearing up my codebase, so I learned to include an escape hatch for when it's stuck between constraints ("email [email protected] if stuck for 'x' turns then halt"). Now it just emails me and waits for further instruction.

To me, perfect is the enemy of good and good is mostly good enough.

If that’s all the code does, sure you could specify every observable behavior.

In reality though there are tens of thousands of “design decisions” that a programmer or LLM is gonna to make when translating a high level spec into code. Many of those decisions aren’t even things you’d care about, but users will notice the cumulative impact of them constantly flipping.

In a real world application where you have thousands of requirements and features interacting with each other, you can’t realistically specify enough of the observable behavior to keep it from turning into a sloshy mess of shifting jank without reviewing and understanding the actual spec, which is the code.

But once you figure that out, it's pretty effective.

Just read the code.

And now the comments are "If it is so great why isn't everything already written from scratch with it?"

Of course the answer is all the things that aren't free, refinement, testing, bug fixes, etc, like the parent post and the article suggested.

For my own work I've focused on using the agents to help clean up our CICD and make it more robust, specifically because the rest of the company is using agents more broadly. Seems like a way to leverage the technology in a non-slop oriented way

https://imgur.com/gallery/i-m-stupid-faster-u8crXcq

(sorry for Imgur link, but Shen's web presence is a mess and it's hard to find a canonical source)

I'm not saying this is completely the case for AI coding agents, whose capabilities and trustworthiness have seen a meteoric rise in the past year.

They just have a lot of users doing QA to, and ignore any of their issues like true champs

Not to say that you don't review your own work, but it's good practice for others (or at least one other person) to review it/QA it as well.

But ignoring that, if humans are machines, they are sufficiently advanced machines that we have only a very modest understanding of and no way to replicate. Our understanding of ourselves is so limited that we might as well be magic.

Well, ignoring the whole literal replication thing humans do.

When you merge them into one it's usually a cost saving measure accepting that quality control will take a hit.

I've been coding an app with the help of AI. At first it created some pretty awful unit tests and then over time, as more tests were created, it got better and better at creating tests. What I noticed was that AI would use the context from the tests to create valid output. When I'd find bugs it created, and have AI fix the bugs (with more tests), it would then do it the right way. So it actually was validating the invalid output because it could rely on other behaviors in the tests to find its own issues.

The project is now at the point that I've pretty much stopped writing the tests myself. I'm sure it isn't perfect, but it feels pretty comprehensive at 693 tests. Feel free to look at the code yourself [0].

[0] https://github.com/OrangeJuiceExtension/OrangeJuice/actions/...

When it comes to code review, though, it can be a good idea to pit multiple models against each other. I've relied on that trick from day 1.

If you're in tech leadership it is your responsibility to make it extremely clear to execs that there is a trade-off being made here. If everyone is going in that direction with eyes wide open then the trade-offs are great.

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

it just means that it might be free for my owner to adopt me, but it sure as hell aint free for them to spoil me

- 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

Code is not the cost. Engineers are. Bugs come from hindsight not foresight. Let’s divide resources between OSs. Let all diverge.

> They are often laggy or unresponsive. They don’t integrate well with OS features.

> (These last two issues can be addressed by smart development and OS-specific code, but they rarely are. The benefits of Electron (one codebase, many platforms, it’s just web!) don’t incentivize optimizations outside of HTML/JS/CSS land

Give stats. Often, rarely. What apps? I’d say rarely, often. People code bad native UIs too, or get constrained in features.

Claude offer a CLI tool. Like what product manager would say no to electron in that situation.

This article makes no sense in context. The author surely gets that.

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.

Compare to other software on Mac such as Pages, Xcode, Tower, Transmission, Pixelmator, mp3tag, Table plus, Postico, Paw, Handbrake etc, (the other i use) etc those are a delight to work with and give me the computing experience I was looking for buying a Mac.

XCode is usually the first example that comes to mind of a terrible native app in comparison to the much nicer VSCode.

Electron apps look the same on each platform therefore they are consistent.

The meta point is the effort required to be consistent with the OS.

You listed MacOS only apps, emphasising the point.

To do a per OS consistent experience is N times the effort.

I didn’t say AI was bad and I acknowledged the benefits of Electron and why it makes sense to choose it.

With 64gb of RAM on my Mac Studio, Claude desktop is still slow! Good Electron apps exist, it’s just an interesting note give recent spec driven development discussion.

>There are downsides though. Electron apps are bloated; each runs its own Chromium engine. The minimum app size is usually a couple hundred megabytes. They are often laggy or unresponsive. They don’t integrate well with OS features.

A few hundred megabytes to a few gb sounds like an end user problem. They can either make room or not use your application.

You can easily buy a laptop for around 400 USD that will run Claude code just fine, along with several other electron apps.

Don't get me wrong, native everything ( which would probably mean sacrificing Linux support) would be a bit better, but it's not a deal breaker.

Should they have re-written Chromium too?

Projects with much smaller budget than Atrophic has achieved much better x-plat UI without relying on electron [1]. There are more sensible options like Qt and whatnot for rendering UIs.

You can even engineer your app to have a single core with all the business logic as a single shared library. Then write UI wrappers using SwiftUI, GTK, and whatever microsoft feels like putting out as current UI library (I think currently it's WinUI2) consuming the core to do the interesting bits.

Heck there are people whom built gui toolkits from scratch to support their own needs [2].

[1] - https://musescore.org/en [2] - https://www.gpui.rs

What really am I to conclude by the mere fact that they used electron? The AI was not so magical that it overcame sense?

Am I to imagine that the fact that they advertise AI coding means I therefore have a window into their development process and their design choices?

I just think the notion is much sillier than all of us seem to be treating it.

Maybe their dog food isn't as tasty as they want you to believe.

What are we to presume from the fact that they did not do that?

And therefore, what?

That’s what’s missing and I think we should just be clear on: it is a design choice to choose electron over writing a native app.

If it really is a design choice then it's a bad decision imo.

these are all also the results of bad design choices or a lack of resources?

When discord and slack started the company was not large so it definitely could have been a lack of resources. Could also have been a bad design choice.

I'm not alone on that either at all. This is a pretty common opinion.

Claude had a chance to really show something special here and they blew it.

Does this work on people usually?

Regardless the only thing keeping those millions of people at this point is lock-in. Even then people are actively looking for ways to move away from it. I'm witnessing the migration now and am looking forward to the day I don't have to hard restart the client 2-3 times a day.

What does any of the malaise about discord have to do with their choice of runtime?

It is an untested hypothesis that if discord had a native app, all the problems that people complain about would disappear. I think people in hacker news like to just assert the hypothesis because sounds better than cross platform. But in this particular case, it is fundamentally untested. We simply don’t know that the app would be better if it were native.

I just saw your other posts in this thread though.

We can all talk about how this or that app should be different, but the idea is "electron sux => ????? "

Why should I care that they didn't rebuild the desktop app I don't use. Their TUI is really nice.

What's in that for me?

1. Anthropic had no problem spending tens of thouands of dollars of tokens re-writing the C compiler a couple weeks ago before abandonining it within hours of launch, despite promising that fixes were coming in the following days. 2. Regardless are you arguing that re-writing Chromium would have been a good solution for the original suggestion of native apps? Aren't there better existing approaches from companies that don't claim to have the best coders, nor are worth hundreds of millions, billions, tens of billions, nor hundreds of billions of dollars, so I'm unsure why you made that specific suggestion? Wouldn't pointing to an existing product's native approach be a better suggestion?

What really is the argument and the threshold we’re proposing here?

I just think the idea that we have some sort of vision into their design process because we can look at some externally visible feature of the design is silly. Am I supposed to presume the same thing about capabilities for every shop that creates an electron app? Am I supposed to take anyone’s native app and see that as a claim that they’ve cracked coding?

These things are just orthogonal to the questions at hand. They’re just simply not related and everyone here seems to pretend like they are.

This is based on the premise that LLM-corpos are right. And if they are wrong, then the laughs about their hypocrisy is doubly deserved :) .

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.

You can use those expensive engineers to build more stuff, not rewrite old stuff

Why create Linux when UNIX exists?

Why create Firefox when Internet Explorer exists?

Why Create a Pontiac when Ford exists?

Why do anything you think can be done better when someone else has done it worse?

if it gets solved, (1) we are all f....d! Not only software engineers. (2) they can rewrite it using Assembly. they == AGI

Given how much they pay their developers, the Claud app probably cost at least 2, and likely 3, orders of magnitude more to build.

If their AI could do the same for $2m they'll definitely do that any day.

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.

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

Also if you haven't heard, disk space is no longer as cheap, and RAM is becoming astoundingly expensive.

So the footprint of the whole browser might be heavy, but each individual tab (origin) adds only a little extra.

Unfortunately both Tauri and Electron suck in this regard - they replicate the entire browser infrastructure per app and per instance, with each running just a single 'tab'.

And I share your concern for both disk space and RAM - but the solution here is to move away from browser tech, not picking a slightly differently packaged browser.

Tauri's story with regards to the webview engine on Linux is not great.

1: https://github.com/NeodymiumPhish/Pharos

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.

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.

The disturbing fact is that AI is simply smarter than us by a stupendous margin. Anything you do that involves thinking can be done better by the AI. We are obsolete when it comes to being smart.

I was in denial about this for a couple years, but I understand now.

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

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

clearly the code isn’t free and writing for raw win32 is painful.

https://www.qt.io/development/open-source-lgpl-obligations

If only AI had more Liquid Glass, lol

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'll see, I guess...

Sewing by hand is mostly a hobby but it doesn't seem to be a problem for the textile industry. Planting seeds by hand in a field is a hobby too. So is cutting down trees with an ax.

It sucks but our skill set is (or will soon be) worthless. If it's a consolation, the same is true for anyone who makes money with their brain.

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.

Really and truly, what do we KNOW about Anthropic because the Claude desktop app is an electron app?

I submit the answer is “very very little.” But the author and lots of people in this thread seem willing to infer quite a fucking lot!

I guess I don't understand how people don't see something like 20k + an engineer-month producing CCC as the actual flare being shot into the night that it is. Enough to make this penny ante shit about "hurr hurr they could've written a native app" asinine.

They took a solid crack at GCC, one of the most complex things *made by man* armed with a bunch of compute, some engineers guiding a swarm, and some engineers writing tests. Does it fail at key parts? Yes. It is a MIRACLE and a WARNING that it exists at all? YES. Do you know what you would have with an engineer-month and 20k in compute trying to write GCC from scratch in 2 weeks in 2024? A whole heck of a lot less than they got.

This notion that everything is the same just didn't make contact on 2025, and we're in 2026 now. All of software is already changing and HN is full of wanking about all the wrong stuff.

The title doesn't even seem to be intended as a shot in the night, despite that being how most of the HN took it. I.e. the author isn't saying "don't use agents because Claude Code is written in Electron" they are genuinely looking at why one would still have their agents write an Electron app over native when using coding agents.

Really truly what do we know about them based on that decision? I submit the answer is basically nothing.

Instead, we’re sort of coasting on priors and vibes about “native” tool kits being better. And that’s just catnip for people on the Internet who want to talk shit about code and don’t know what the fuck they’re talking about.

If native is a stand in for better in your mind and you conclude that they made a choice that was worse because it’s not native then therefore you can conclude that they are bad somehow. But the connective tissue there is not whatever they’re designing choice is (and of course we have no vision into the actual choices). It’s the un-investigated prior. That native is good and cross platform is bad. That’s really what people are arguing in this thread.

And the only reason we don’t see that is completely fucking ridiculous is because we are also interested in talking about how AI is bad.

So everyone gets to have two bites of the cookie and nobody gets to defend an actual argument. It’s so silly that I don’t think that we can claim that the piece is actually much more moderate and subtle than everyone is reading it to be. Because that’s kind of a dastardly position too. It allows the main argument to be advanced, and whenever it is questioned, one can retreat to claims of nuance.

Instead, let’s just say that it’s silly.

The article doesn't go as far as saying Electron is bad or judge Anthropic based on their use of it. It says Electron has downsides which are dramatically outweighed by the upsides and then shows that calculus remains true (i.e. the benefits of Electron still outweigh any of the potential downsides) even when using LLMs as coding agents. The article is not setting out to ridicule anything, it's investigating why Electron is still a good choice in the coding agent use case by looking at one such app (the Claude desktop app) written very close to home for coding agents as an example.

About the only thing the article can be said to ridicule at all is that the Claude app is slow and buggy (which is accurate IMO) but it's never saying that to imply it's impossible to solve that because it's an Electron app or that it means one should not use coding agents. The rest of the article really stands to state quite the opposite.

As the article concludes, it is a pro-Electron usage pro-coding-agent piece. I.e. that the Claude desktop app is written in Electron is NOT evidence either Claude or Electron must be bad:

> For now, Electron still makes sense. Coding agents are amazing. But the last mile of dev and the support surface area remains a real concern.

That last mile is where the author places the problems, and they had placed them there regardless whether one uses Electron or coding agents, so it's hard to take it as a hit piece for those two things.

"The state of coding agents can be summed up by this anecdote:

Claude spent $20k on an agent swarm implementing (kinda) a C-compiler in Rust, but desktop Claude is an Electron app."

We haven't made it 100 words in and we already have the core claim. In case we missed it, the author puts it in an inset later:

>So why are we still using Electron and not embracing the agent-powered, spec driven development future?

We get to the end where the author says:

"For now, Electron still makes sense. Coding agents are amazing. But the last mile of dev and the support surface area remains a real concern."

That's both true and and misleading. It's misleading because we can all agree with this sober-minded concluding statement and forget it's just based on "Electron bad, native good". The real logical sequence the author needs us to follow is:

Anthropic said code is free now. > Native code is harder than that for a cross platform runtime > Anthropic releases an app on a cross-platform runtime > code must not be free.

That is only true iff there's absolutely no other design tradeoff! Did they pick electron because robots are bad at the last mile? Maybe. It's pretty dubious, given the MANY MANY other people who made electron apps before AI could code. It's also not at all clear "native good, electron bad" is true at all. It reminds me STRONGLY of "jQuery bad / native good" which was also groundless.

I.e. yes, coding agents can't make everyone happy and do 100% of everything - but by the end the opposite of the expected point from that is reasoned. It may not be exhaustive, but that does not automatically mean the sole point is reductionist. It only takes one counterexample of reasoning to show a point invalid, so if you don't assume the goal is to make Electron and Claude actually sound bad then these points are not really problematic.

As someone who sees themselves more towards the center of the AI debate I found the article surprisingly refreshing in not trying to argue absolutes about extremes. Others who sit more towards the extremes probably see it as an attack piece (regardless of which extreme) just because it doesn't go as far as they'd like in each regard.

You can't conclude anything reliably from their choice of electron over native apps. You can't. You can ASSERT things like the author does, like "The state of coding agents can be summed up by this fact: Claude spent $20k on an agent swarm implementing (kinda) a C-compiler in Rust, but desktop Claude is an Electron app." That's a fine assertion. It's just not a fact or knowledge about any kind of design decision.

The whole argument revolves around knowing that electron is a compromise because one could just make multiple native apps without asking if "make multiple native apps" serves a design need the developers had at all! If the developers (like many others who use electron) did not declare "we want to make native apps" or have a need that caused that to become a desire, then inferring that using electron is a compromise at all is groundless. It may never have been a compromise to begin with!

"We have cheap elevators, why aren't all floor connections using them?

The state of elevators can be summed up by this fact: The OTIS Elevator Company Factory Building cost $x million to build, but it still has stairs"

The only thing this section asserts is "stairs seem to still be chosen". It's not actually asserting anything else yet, it's grabbing the attention of those who commonly assume this must mean a lot of things. It sounds exactly like something someone who would want to say Elevators and OTIS are useless bad crap would start with, but intentionally stops short of that conclusion from these to instead take things in a different direction which is still compatible with this information.

The assertions on Electron actually start later on here, and do not source from the design decisions of the Claude desktop app:

> There are downsides though. Electron apps are bloated; each runs its own Chromium engine. The minimum app size is usually a couple hundred megabytes. They are often laggy or unresponsive. They don’t integrate well with OS features. (These last two issues can be addressed by smart development and OS-specific code, but they rarely are.

These are not sourced from the design decisions of Anthropic. The first is an assertion of fact of what Electron is, a bundled instance which runs a full browser engine resulting in a large minimum app size. The next two assertions are actually not assigned to Electron itself, rather development effort. The only poorly sourced assertion here is that such apps are rarely well optimized, but if you take issue with that it does not actually impact the rest of what the article talks about.

The article then spends some time talking about why Electron is actually a common choice despite this, which eventually leads to the actual assertions about Electron's usage in the Claude app:

> But we’re still leaning on Electron. Even Anthropic, one of the leaders in AI coding tools, who keeps publishing flashy agentic coding achievements, still uses Electron in the Claude desktop app. And it’s slow, buggy, and bloated app.

There are 3 assertions here.

1. Anthropic has shown all sorts of flashy things with AI coding tools

2. The app is still using Electron

3. The app is slow, buggy, and bloated.

These assertions are not interdependent, they are just observations of the app. The article is still not arguing Electron can only be slow/buggy (though it has previously asserted it must be bloated by nature) nor is the app asserting why Anthropic has made these design choices yet. It is still following the train of thought one might be biased to from the original thought but carrying it further to perhaps unexpected conclusions.

The question in the reader's mind the article seeks to next pre-emptively answer is now stated: "So why are we still using Electron and not embracing the agent-powered, spec driven development future?". Most likely the reader has "make it a native app" as the first path, but the article already laid out 2/3 of these things can be solved with a smartly written Electron app. In either case, the article is not asserting why the Claude desktop team chose/chooses a particular design choice, it's seeking to answer why having great coding agents isn't necessarily a free answer to slowness, bugginess, and bloat in a cross platform app.

This is where the article finally makes its core argument:

> For one thing, coding agents are really good at the first 90% of dev. But that last bit – nailing down all the edge cases and continuing support once it meets the real world – remains hard, tedious, and requires plenty of agent hand-holding.

Using quotes from Anthropics implementation of the C compiler to back up this claim and then continue discussing how the benefits of a common approach over an optimised approach still exists outside of the raw code writing portion of the problem. At this point the article is still avoiding that the Claude desktop team must want a native app as a design goal, only speaking to why coding agents aren't the cure-all for the particular problem set (regardless of approach).

This is why the article concludes:

> For now, Electron still makes sense. Coding agents are amazing. But the last mile of dev and the support surface area remains a real concern.

Rather than:

> For now, it's clear coding agents must suck because Anthropic hasn't used them to come up with a more efficient alternative to the obviously poor choice of Electron or rewrite the app as separate native apps - which must obviously be their goal because coding agents are supposed to be able to write code

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

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.

I don't care if it's QT or a WebView or something else, I just want to lower friction for myself

Yes, feel free to downvote me.

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.

Women, however, are welcome to use electron

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.

Also I refuse to download and run Node.js programs due to the security risk. Unfortunately that keeps me away from opencode as well, but thankfully Codex and Vibe are not Node.js, and neither is Zed or Jetbrains products.

Node apps typically have serious software supply chain problems. Their dependency trees are typically unauditable in practice.

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

https://www.techradar.com/computing/windows/microsoft-has-fi...

It seems like enough people do care to make Microsoft move.

We just don't know how bad it will get with AI coding though. Do you think the average consumer won't care about software quality when the bank software "loses" a big transition they make? Or when their TV literally stops turning on? People will tolerate shitty software if they have to, when it's minor annoyances, but it makes them unhappy and they won't tolerate big problems for long.

I've see every kind of wrong actively in production and 99/100 times no one cared enough to fix it. Even when it was losing money.

I use Opus 4.6 (for complex refactoring), Gemini 3.1 Pro (for html/css/web stuff) and GPT Codex 5.3 (workhorse, replaced Sonnet for me because in Copilot it has larger context) mostly.

For small tools. But also for large projects.

Current projects are:

1) .NET C#, Angular, Oracle database. Around 300k LoC.

2) Full stack TypeScript with Hono on backend, React on frontend glued by trpc, kysely and PostgreSQL. Around 120k LoC.

Works well in both. I'm using plan mode and agent mode.

What helps a ton are e2e playright tests which are executed by the agent after each code change.

My only complain is that it tends to get stutters after many sessions/hours. A restart fixes it.

$39/mo plan.

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

What bugs are you seeing? I use Claude Code a lot on an Ubuntu 22.04 system and I've had very few issues with it. I'm not sure really how to quantify the amount of use; maybe "ccusage" is a good metric? That says over the last month I've used $964, and I've got 6-8 months of use on it, though only the last ~3-5 at that level. And I've got fairly wide use as well: MCP, skills, agents, agent teams...

maybe we don't have AGI to prevent all bugs. but surely some of these could have been caught with some good old fashioned elbow grease and code review.

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.

https://www.businessinsider.com/anthropic-claude-code-founde...

nailing down all the edge cases

At most, VS Code might say that it has disabled lexing, syntax coloring, etc. due to the file size. But I don't care about that for log files...

It still might be true that Visual Studio Code uses more memory for the same file than Sublime Text would. But for me, it's more important that the editor runs at all.

The answer of course is that it can’t do it and maintain compatibility between all three well enough as it’s high effort and each has its own idiosyncrasies.

In python it was very nearly a 1-shot, there was an issue with one watermark not showing up on one API endpoint that I had to give it a couple kicks at the can to fix. Go it was able to get but it needed 5+ attempts at rework. Rust took ~10+, and Zig took maybe 15+.

They were all given the same prompt, though they all likely would have dont much better if I had it build a test suite or at least a manual testing recipe for it to follow.

That is why everyone jumped to building in Electron because it is based on web standards that are free and are running on chromium which kind of is tied to Google but you are not tied to Google and don’t have to pay them a fee. You can also easily provide kind of the same experience on mobile skipping Android shenigans.

It's LGPL, all you have to do is link GTK dynamically instead of statically to comply.

> to build win32 you have to pay developer fee to Microsoft.

You don't.

Not really, you can self sign but your native application will be met with a system prompt trying to scare user away. This is maddening of course and I wish MS, Apple, whatever others will die just for this thing alone. You fuckers leveraged huge support from developers writing to you platform but not, it is of course not enough for you vultures, now let's rip money from the hands that fed you.

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?

Not everyone is running the latest and greatest hardware, very few actually have the money for that. If you're running hardware from before this decade, or especially the early 2010s, the difference between an Electron app and a native app is unbelievably stark. Electron will often bring the device to its knees.

This is particularly pertinent on bulk-purchased corporate and education machines which are loaded down with mandated spyware and antivirus garbage and often ship with CPUs that lag many years behind, and in the case of laptops might even have dog slow eMMC storage which makes the inevitable virtual memory paging miserable.

Real users complain differently: "My machine is slow". Electron itself is not very heavyweight (though not featherweight), but JS and DOM can cost a lot of resources. Right now my GMail tab has allocated 529 MB.

> That's not due to Electron.

Of course, but it takes some careful thought. BTW e.g. Qt apps can be pretty memory-hungry, too.

> good enough for Microsoft Teams

It's not easy no pick a more "beloved" application.

What an Electron app usually would miss is things like global shortcuts managed by macOS control panel, programmability via Automation, and the L&F of native controls. I personally don't usually miss any of these, but users who actually like macOS would usually complain.

I personally prefer to run Electron-ish apps, like Slack, in their Web versions, in a browser.

The free ride of ever increasing RAM on consumer devices is over because of the AI hyperscalers buying all fab capacity, leading to a real RAM shortage. I expect many new laptops to come with 8GB as standard and mid-range phones to have 4GB.

Software engineers need to start thinking about efficiency again.

These workers complain about performance on the machines we can afford. 16GB RAM and 256GB SSDs are the standard, as is 500MB/sec. internet for offices with 40 people, and my plans to upgrade RAM this year were axed by the insane AI chip boondoggle.

People on HN need to understand that not everyone works for a well-funded startup, or big tech company that is in the process of destroying democracy and the environment in the name of this quarter's profits!

BTW Teams has moved away from Electron, before it did I had to advise people to use the browser app instead of the desktop for performance reasons.

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.

If as your CEO says “coding is largely solved”, why is this the case?

Or is your CEO wrong and coding is not largely solved?

If you’re gonna start speaking for and defending your company though and your company CEO has made asinine statements that are related, I’m gonna ask.

If coding SOLVED HOW COME APP BAD.

Edit: (1) because most of the complexity lies in the tool chains that are integrated, like compilers and linters, and (2) because there’s much more complex software out there, mostly at the intersection of engineering domains, to name a few: ballistic guidance systems, IoT and networking, predictive maintenance systems, closed-loop process optimization systems, SLAM robotics

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.

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.

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.

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.

Using IntelliJ I actually find myself wishing for an integrated webview of Github Copilot. The native view is absolutely terrible, jumping up and down non stop.

The app handles NuGet dependency resolution on the fly, catches runtime errors and feeds them back to the model for self-correction, and can export standalone executables (WPF for Windows, Avalonia for cross-platform). Everything is self-contained — users don't need to install any SDKs, IDEs, or toolchains.

I'm a teacher, not a startup founder, and I've been trying to market this commercially without much luck. Seriously considering open-sourcing the whole thing. Would love to hear what people here think about the native-vs-web approach for AI-generated applications.

Happy to do a quick demo if anyone's curious.