But if AI can maintain code bases so easily, why does it matter if there are 3? People use electron to quickly deploy non-native apps across different systems.
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.
1. Anthropic has no problem burning tens of thousands of dollars of tokens on things that have zero real-world value, such as implementing a C compiler that as far as I can tell they don't intend to be used in the real world - for example, they announced it on Feb 5, promising "Over the coming days, I’ll continue having Claude push new changes if you want to follow along with Claude’s continued attempts at addressing these limitations" but there have been zero code commits since Feb 5 (the day they announced it). Wouldn't it make far more sense for a company to invest tokens into their own product than burning them for something that may be abandoned within hours of launching, with zero ongoing value to their company or their customers?
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?
But the one times the resources didn't solve the problem, clearly, since we are talking about it. And they claim that AI makes it trivial to port to do this sort of things so it would not be 3x the resources.
> But if AI can maintain code bases so easily, why does it matter if there are 3? People use electron to quickly deploy non-native apps across different systems.
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.
One thing to consider is that "native" apps are considered the gold standard of desktop UIs, but a overwhelming share of users… don’t care. I, for one, don’t necessarily enjoy Qt apps. I think the only one I still use is KeepassXC and it’s trash to me, just slightly better than Keepass2. I much prefer the Bitwarden Electron app.
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)
Did you ever consider that perhaps for other people when something is unreasonably slow and consuming all of their battery, the "polish" is really not that high on the list of important characteristics?
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).
Ok but did you consider some people care about polish and prefer apps with an attention to design, and not so much about consistency with other apps? Why are your tastes more important?
Not my taste, the requirements of not crashing and not being horribly slow come before any polish. Any software engineering course will teach you that.
Yeah, I'm kind of disheartened by the number of people who still insist that LLMs are an expensive flop with no potential to meaningfully change software engineering.
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.
Yea what? This is exactly why they should switch to native apps. Native apps are not harder to maintain than JavaScript especially with LLM guidance on APIs and such. I don't understand why your confidence in LLM code ability means you don't think it can succeed with native apps
No it is not the same with LLMs because LLMs are a multiplier that makes the overall work less compared to without them, and that includes support burden. "Support" is a hand wavy word to dismiss the fact that it consists of writing code and fixing bugs, all of which LLMs can help massively with now. They meaningfully change software engineering which you are ignoring when you assume the same cost of pre-LLM development on multiple platforms.
If without an LLM maintaining three apps is 3x the work and an LLM is a multiplier, then it's still 3x the work.
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.
