I've been evaluating truly native x-platform GUI frameworks for a while and GPUI[0] from the zed team along with longbridge/gpui-component[1] looks the most promising.
Though I haven't tested it too much other than building small personal tools like a work habit tracker, it's very well documented and looks great. Gave me a good excuse to try the language again as well.
I would say that the real reason is because "it works". As simple as that.
The first thing you need when you make something new is making it work, it is much better that it works badly than having something not working at all.
Take for example the Newcomen engine, with an abysmal efficiency of half a percent. You needed 90 times more fuel than an engine today, so it could only be used in the mines were the fuel was.
It worked badly, but it worked. Later came efficiency.
The same happened with locomotives. So bad efficiency at first, but it changed the world.
The first thing AI people had to do is making it work in all OSes. Yeah, it works badly but it works.
We downloaded some Clojure editor made in java to test if we were going to deploy it in our company. It gave us some obscure java error in different OSes like linux or Mac configurations. We discarded it. It did not work.
We have engineers and we can fix those issues but it is not worth it. The people that made this software do not understand basic things.
We have Claude working in hundreds of computers with different OSes. It just works.
They could have done better. They chose the path of least resistance, putting in the least amount of effort, spending the least amount of resources into accomplishing a task.
There's nothing "good" about electron. Hell, there are even easier ways of getting high performance cross platform software out there. Electron was used because it's a default, defacto choice that nobody bothered with even researching or testing if it was the right choice, or even a good choice.
"It just works". A rabid raccoon mashing its face on a keyboard could plausibly produce a shippable electron app. Vibe-bandit development. (This is not a selling point.) People claiming to be software developers should aim to do better.
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.
Let's assume for the moment the developers are doing about the best they can for the goals they're given. The slowness is a product decision, not an engineering problem. They are swimming in cash and could write a check to solve the problem if they cared. Evidence is they have other priorities.
That’s the hard swallow. End users only care about the UX and it working. They don’t care how succinct your code is. They indirectly care about its performance.
At least it seems like a lot more apps are cross-platform than before. I wouldn't call the native devs lazy for not making a Mac version of their Windows app.
Early games frequently took the approach of inventing an interpreted machine code in which the bulk of the game would be written, with an assembly interpreter that would need to be rewritten for each target IA and modified for the specific peripheral mixes of each target machine.
The approach runs slower than a game written directly in assembly, but the cost to port to different architectures is much lower.
Sort of like Electron trades off native performance and look-and-feel to make multi-platform apps much more achievable.
IMO the OS vendors failed everyone by refusing to even attempt to agree on a common API for UI development, paving the way for web browsers to become the real OS and, ultimately, embedded browsers to be the affordable and practical way to be cross platform.
Realize, though, that just grabbing a frame buffer is not a thing anymore. To render graphics you need GLES support through something like ANGLE, vectors and fonts via Skia, Unicode, etc. A web browser has those things. Any static binary bundling those things is also gonna be pretty large.
And JavaScript is very good at backwards compatibility when you remove the churn of frameworks (unfortunately Electron doesn't guarantee compatibility quite as far back)
I agree, this is clearly an indictment against LLMs. If LLMs and agents were capable they'd 100% write it natively but they realize the current limitations.
I've programmed in every native Windows GUI starting with MFC. Used Delphi too. I've even created MS-DOS TUI apps using Turbo Vision.
Compared to the web stack and Electron, native GUI APIs are complete shit. Both for the programmer, but also for the user.
Reactive UI (in the sense of React, Vue, ...), the greatest innovation in UI programming ever, was made popular by web-people.
Unless you write some ultra-high performance app like a Browser, a CAD app, a music production app, it doesn't make any sense to use native GUIs. Takes longer to program, the result is uglier and with less features. And for those ultra high performance apps you don't use the native UI toolkit anyway, you program your own widgets since the native ones are dog shit and slow.
Don't forget about all the embedded UIs (kiosks, appliances, car infotainment, industrial equipment, ...), those computers are weaker and it makes a ton of sense to use native toolkits there.
They tried to replace our Qt GUI at work in this space with a react based one, the new UI ran like utter shit comparatively, even after a lot of effort was spent on optimisation.
Also, most of the world don't use high end developer laptops. Most of the world is the developing world, where phone apps on low end Android phones reign supreme.
Electron is very easy to deliver a good quality app for everything but absolute power users.
Yes it's horribly slow but it enables rapid experimentation and it's easy to deliver the wide range of UI integrations you are likely to want in a chat-esq experience.
It’s not even horribly slow. It works fine. It’s just a chat program. It’s the right trade off for the job.
Doing more work for no reason is stupid even if you the have money of a small nation.
The inevitable differences between platforms you get with all native everything isn’t a good user experience, either. Now you need to duplicate your documentation and support pages and have support staff available to address every platform. And what’s the payoff? Saving 80MB of RAM? Gaining milliseconds of latency that Joe Business will never notice as he’s hunt and pecking his way through the interface?
I thought we were done with Electron hate articles. It’s so 2018 to complain about it. It’s like talking about millennials and their skinny jeans. Yawn.
On iOS there isn't always a choice to not build something native. For example, I can't install Navidrome as a PWA because Apple doesn't properly support audio playback for PWAs. I ended up writing a client that suited my listening habits.
To read ePubs, however, I was able to write a PWA leveraging epub.js because no native APIs were required.
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].
I have been using Tauri for a macOS app I'm making[1] and it has been great. The app is only 11MB and I've had most of the APIs I'd need.
However, there are still some rough edges that have been annoying to work with. I think for my next project I will actually go back to electron. There are two issues that caused me pain:
1. I can't use Playwright to run e2e tests on the tauri app itself. That's because the webview doesn't expose the Chrome DevTools Protocol, and the tauri-driver [2] does not work on MacOS.
2. Security Scoped Resources aren't fully implemented which means if a user gets the app through the app store the app won't be able to remember file permissions between runs [3]. It's not too much of an issue since I probably won't release it on the app store, but still annoying.
But I hope Tauri continues to grow and we start seeing apps use it more.
+1 for Tauri, I've been using it for my recent vibe-coded experimental apps. Making rust the "center of gravity" for the app lets me use the best of all worlds:
- declarative-ish UI in typescript with react
- rust backend for performance-sensitive operations
- I can run a python sidecar, bundled with the app, that lets me use python libraries if I need it
If I can and it makes sense to, I'll pull functionality into rust progressively, but this give me a ton of flexibility and lets me use the best parts of each language/platform.
Its fast too and doesn't use a ton of memory like electron apps do.
Also, Rust's strong and strict type system keeps Claude honest. It seems as if the big LLM models have trained on a lot of poorly written TypeScript because they tend to use type assertions such as `as any` and eslint disable comments.
I had to add strict ESLint and TypeScript rules to keep guardrails on the coding agents.
I find it a bit odd how much people talk up the Rust aspect of Tauri. For most cases you'll be writing a Typescript frontend and relying on boilerplate Rust + plugins for the backend. And I'd think most of the target audience would see that as a good thing.
I working on a project using tauri with htmx. I know a bit uncommon. But the backend part use axum and htmx. No Js/Ts UI. It's fast, reliable and it work well. Plus its easy to share/reuse the lib with the server/web.
I am considering a Tauri app, but still wondering about architecture design choices, which the docs are sparse about. For instance the Web-side may constitute a more full-blown, say NextJS, webapp. And include the database persistance, say SQLite based, on the web side too, closest to the webapp. That goes against the sandboxing (and best-practice likely), where all platform-related side effects are dealt with Platform-side, implemented in Rust code. I wonder if it is a valid choice. There is a trade-off in more ease of use and straightforwardness vs. stricter sandboxing.
At least with Tauri it's easy to both make the choice and change it later if you want to. I think the docs are sparse because it's your decision to make. I've done it both ways and there are pros and cons. If you use the sqlite plugin and write the actual statements on the JS side then you don't need to worry about the JS<->Rust interface and sharing types. Easier to just get going. If you write your own interface then you probably want to generate TS types from Rust. I think a big advantage to the Rust interface way is that it makes it easier to have the web side be dual purpose with the same code running on the web and in Tauri - the only difference being whether it invokes a tauri call or an API call.
Looks cool, but the phrase 'build applications with the flexibility and power of go' made me chuckle. Least damn flexible language in this whole space.
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.
> LLM-driven development could land on a safer language
Why does an LLM need to produce human readable code at all? Especially in a language optimized around preventing humans from making human mistakes. For now, sure, we're in the transitional period, but in the long run? Why?
"It has been lost in AI money-grabbing frenzy but a few years ago we were talking a lot about AIs being “legible”, that they could explain their actions in human-comprehensible terms. “Running code we can examine” is the highest grade of legibility any AI system has produced to date. We should not give that away.
"We will, of course. The Number Must Go Up. We aren’t very good at this sort of thinking.
Because the traits that make code easy for LLMs to work on are the same that make it ideal for humans: predictable patterns, clearly named functions and variables, one canonical way to accomplish a task, logical separation of concerns, clear separation of layers of abstraction, etc. Ultimately human readability costs very little.
> For now, sure, we're in the transitional period, but in the long run? Why?
Assuming that after the transitional period it will still be humans working with ai tools to build things where humans actually add value to the process. Will the human+ai where the ai can explain what the ai built in detail and the human leverages that to build something better, be more productive that the human+ai where the human does not leverage those details?
That 'explanation' will be/can act as the human readable code or the equivalent. It does not need to be any coding language we know today however. The languages we have today are already abstractions and generalizations over architectures, OSs, etc and that 'explanation' will be different but in the same vein.
Well, IMO there's not much reason for an LLM to be trained to produce machine language, nor a functional binary blob appearing fully-formed from its head.
If you take your question and look into the future, you might consider the existence of an LLM specifically trained to take high-level language inputs and produce machine code. Well, we already have that technology: we call it a compiler. Compilers exist, are (frequently) deterministic, and are generally exceedingly good at their job. Leaving this behind in favor of a complete English -> binary blob black box doesn't make much sense to me, logically or economically.
I also think there is utility in humans being able to read the generated output. At the end of the day, we're the conscious ones here, we're the ones operating in meatspace, and we're driving the goals, outputs, etc. Reading and understanding the building blocks of what's driving our lives feels like a good thing to me. (I don't have many well-articulated thoughts about the concept of singularity, so I leave that to others to contemplate.)
I’ve only built some basic CRUD-type apps in SwiftUI, but I thought it was pretty nice. The APIs seem well thought-out, I needed less code than I would have to do the same thing in React, and the default styling looked quite professional.
Of course, the React ecosystem and community is enormous. I bet if I was building something complex, I would have gotten frustrated building it all from scratch in SwiftUI when I could just reach for a React component library.
Somehow, a CAD program, a 3D editor, a video editor, broadcasting software, a circuit simulation package, etc are all native applications with thousands of features each - yet native development has nothing to offer?
"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.
But on the other hand the claude app is garbage… https://github.com/anthropics/claude-code/issues/22543
obviously native apps can be garbage too, but I must say electron apps have a surprisingly high incidence of terrible performance issues, unsure if it’s a correlation or causation issue
I love Claude but both the desktop and the web apps are incredibly janky when compared with their OpenAI counterparts (I won’t even comment on Gemini’s because it’s also incredibly broken and unreliable).
Start times are atrocious, long conversations literally break rendering (and I’m using the desktop app on a MacBook Pro with an M3 Pro CPU and 36 GB of RAM so an electron app shouldn’t feel so janky so frequently, right?).
IMHO they just don’t care right now (and I get it from their perspective) but I’m pretty sure there’s a lot of low hanging fruit they could fix to make the experience 5x or even 10x smoother. Claude Code (TUI) is also another memory hog and I’ve even had Ghostty literally crash with enough open sessions.
Fortunately Anthropic models are also incredibly so at least I’ve been able to speedrun my own desktop client using Tauri and fix many of the issues I encounter every day. I might release it at some point.
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.
The rise of Electron was purely because you can share the codebase for real with the web app (for lots of apps it is their main focus) and get cross-platform support for free.
Native apps are not bad to develop when using Swift or C#, they are nice to use and their UI frameworks are fine, it's just that it requires a separate team. With Electron you need much less, simple as that.
> As for the rest: minor variations in traffic light positioning and corner radii are topical but hardly indicators of decaying platorms.
I think it shows how important the platform itself is to the company. The system settings app on macOS is literally slow to change the topic (the detail page is updated like ~500ms after clicking).
I personally love to develop desktop apps but business-wise they rarely make sense these days.
> Disagree. The "rise of Electron" is due to the ubiquity of the JS/HTML/CSS/Node stack, and many junior developers knowing nothing else.
with all due respect - hard disagree. in what place on Earth to Junior Devs make these types of decisions?? Or decision makers going “we got these Juniors that know JS so it is what is…”
I don't believe they were implying they would make the decision. It's expensive to have your team learn new skills from scratch, and management won't want to pay for that if they don't have to.
I have been coding for 30 years now and I have never encountered a technical decision like choosing technology (e.g. Electron) for anything important to the company being made with "oh, we must use X because so and so knows X"
Maybe if there was a toss-up between X and Y or something like that but to flat-out pick Electron because you have people that knows JS is madness
I'm thirty+ years in too, and it happens all the time - particularly in smaller operations. Resourcing constraints, disinclination to provide training, tight deadlines, etc.
With regards to "we've lost native" isn't local-first the opportunity to bring it back in a paradigm shift that deals a blow to both the browser and cloud vendor hegemonies?
With today's processors and speeds, there really is no difference in performance of these Electron apps vs Native and anyone disagreeing just dislikes the JS ecosystem
Based on "anyone disagreeing just dislikes the JS ecosystem", I feel like you might not want to grace me with a response, but I disagree /somewhat/.
Electron and web technology generally is certainly more performant than it once was, and I think people do malign Electron specifically a bit too much. VS Code continues to be the anti-example. It's always rather surprising it's just a web view, even on lower end hardware. (A several year old raspberry pi for example)
(Please note, I said "surprising it's just a web view", not "it's more performant than it could be if built differently".)
I think the main difference people tend to experience is a lack of care. I would say, for reasons I am NOT sure are causal, electron apps do seem to tend towards worse experiences on average in my experience. I think on the web, a quick flash of unstyled content or that ghost of the element you accidentally dragged instead of clicked are seen as just minor issues, because they're expectations of the web. If things go REALLY wrong, I have a whole rock solid toolbar above the app that lets me refresh if I think I'm in some infinite loop, or the URL bar I can look at if I'm not sure what page I was just redirected to. The back button promises to return me to where I was before. The browser is caging-in applications for me, so it's fine if they're a bit rowdy.
But using an application that is pretending to NOT be a web browser, seeing any web-quirk feels like I'm staring at rusted rebar in a cracked concrete bridge. The bridge still works, but now I'm aware of the internals of it and maybe that makes me feel a little more uneasy about standing on it. There is no back button if something goes wrong, and if there is, the app itself is rendering it. It's of course possible to hide that reality from me, but you need to care about sealing up all the cracks that let me see the rowdy internals.
To be fair, maybe that's just me that feels that way. And I do rather like the JS ecosystem.
I disagree because yes I dislike the whole JS ecosystem and the language itself. But also because Electron apps in general are resource monsters and while some are better than the others, Claude Desktop is definitely not one of them. Hell even their website will crash on Firefox very often.
The thing people miss is isn't not that there aren't downsides (power, memory, disk size, dependency ecosystem size etc etc) it's that they're still completely outweighed by the upsides of write-once-ship-all for authors.
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.
When I complain about a lack of “native” software I pretty much always mean the platform-provided defaults. Not some cross-plaform UI toolkit that happens to be “native” code. Most apps that I see using QT on Mac or whatever would provably be better as Tauri apps.
Respectfully: skill issue. My employer ships software native for Windows, Mac, iOS and Android. Different codebases for all (though they share a lot of common stuff), all maintained by a shockingly small team.
It’s absolutely achievable if you give a shit about your products and I’m long over hearing the bevy of usual fucking excuses from software houses often magnitudes larger than us who struggle to even keep their electron shit working correctly.
Native is shorthand for "integrated into the platform". Lowest-common-denominator stuff that Electron gives feels correct nowhere (looking at you, Slack). The very best cross-platform applications implement their UI using the native platform idioms on the native platform technologies, and share the core of their logic. The current best example I have is Ghostty which feels perfectly at home on either macOS or Linux.
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.
You've basically described Flutter and Jetpack compose(for desktop). The problem really does turn into effort to pay off, even if we stayed with JS and the rendering engine, figured out a way to compile JS into native code and completely stripping all of the unused functionality and doing the same thing with the rendering engine. All of that would need to be made, it's not like electron apps literally crash you machine. You have metrics, hundreds of millions of devices running electron apps at a daily basis. Unless you make your own company, I don't think anyone can convince their leadership to take such a decision.
This wouldn't be an issue if they allowed 3rd party apps or priced their API competitively with their subscriptions. Free software normally fixes these types of problems but is prevented in this case.
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.
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...
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.
What's the advantage of their Electron apps vs using the web? I get that in theory you can use native-only pieces that a browser doesn't support, but in practice a lot of Electron apps are literally the website.
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.
Conversely, an app using native toolkits (at least the Windows ones) will have better chances of running fine under Wine. I've recently had the (dis)pleasure of trying to run some .Net monstruosity with Wine, and oh my got did it not work for obscure reasons.
But overall yeah, from a compatibility perspective, nothing beats Electron. I'm not sure we'd ever get an official Discord client on Linux otherwise.
I really doubt that at this point. Developers have learned that everything Microsoft says to do for Windows, since 2012, will be garbage within a few years. Guaranteed.
Learned Silverlight for Windows Phone development? Too bad, it's UWP now. And the XAML is incompatible.
Learned WinRT for Windows 8/8.1 app development? Too bad, it's UWP now. And the XAML is incompatible.
Packaged your App for APPX? Too bad, it's MSIX now.
You learned how to develop UWP apps? Too bad, the User Interface layer has been ripped out of UWP, it's now called WinUI 3, and it doesn't even run on UWP. Better port your UWP app back to Win32 now, I guess. Why did you even learn UWP again?
You went and learned WinUI 3 like we recommended? Well, unlike WinUI 2, it doesn't have a visual designer, and it doesn't have input validation, or a bunch of other WinUI 2 features. So, depending on what your app needs, you might have a mix of UWP and Win32, because WinUI 2 is UWP-exclusive and WinUI 3 is Win32-exclusive and neither has all the features of the other. Progress!
You built your Windows 8 app with WinJS? Well, sucks to be you, rewrite it in entirety, WinJS was scrapped.
You ported your app from iOS with Project Islandwood? Well, again, that sucks. It was brilliant, it made pulling apps over from iOS much easier, but it's dead. Rewrite!
You decided to hang it all, develop for good old WPF, but wanted to use the Ink Controls from UWP? Great, we developed a scheme for that called XAML Islands which made so you could have some of the best UWP controls in your old app. Then we released WinUI 3, completely broke it, and made it so complicated nobody can figure it out. So broken; even the Windows Team doesn't use it and is writing the modern Windows components for File Explorer with the old version.
But of course, that would require WinUI 2, for UWP, inside Win32 which is the main feature of the broken WinUI 3; which means that the Windows Team has a bastardized version of XAML Islands for their own use that nobody else has (literally), to modernize the taskbar and File Explorer and built-in apps like Paint, that nobody who wants to emulate them can borrow. Their apps don't look modern and their users complain? Suckers, go learn WinUI 3, even though our own teams couldn't figure it out.
You wanted your app on the Microsoft Store? Well, good news, package it together with this obtuse script that requires 30 command-line arguments, perfect file path formats, and a Windows 10 Pro License! Oh, you didn't do that? Do it 5 years later with MSIX and a GUI this time! Oh, you didn't do that? Forget the packaging, just submit a URL to your file download location. Anyone who bothered with the packaging wasted hours for no real purpose.
Did I mention Xamarin? A XAML dialect of its own, that supports all platforms. But it runs on Mono instead of the authentic .NET, so you'd better... work around the quirks. Also it's called MAUI now, and runs on .NET now. But that might break a few things so hang around for over a year's worth of delays. We'll get it running for sure!
Oh, and don't forget about ARM! The first attempt to get everyone to support ARM was in 2012 with a Windows version called... No, no, no. Go past this. Pass this part. In fact, never play this again. (If you want to imagine pain, imagine running Windows and Microsoft Office on a ARM CPU that came three generations before the Tegra X1 in the Nintendo Switch. Surface RT ended with a $900M write-off.)
And so on...
Or, you could just ignore everything, create a Windows Forms (22 years strong) or WPF app (17 years strong), and continue business like usual. Add in DevExpress or Telerik controls and you are developing at the speed of light. And if you need a fancier UI, use Avalonia, Electron, React, or Flutter.
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.
> with the same buttons and corner radius as other apps on the system
I just checked: No, the corner radius is different. I'm personally not very bothered by that, but it's just empirically true.
> Electron is a native wrapper for web content. The wrapper is still native.
In my view, the problem isn't that it's a wrapper, but rather that it's that it's a bad wrapper of a bad runtime (i.e. the incredibly bloated JS/web stack).
UIKit etc never made sense to me after years, CSS also didn't make sense, but right out of the box I understood React. And with hooks, it's way less boilerplate than the UIKit ways.
Separate from that, Apple doesn't seem to mind breaking native macOS apps, to the point where most devs treat native code like a liability on Mac but ok on Windows.
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?
I don't know for a fact, but I'd bet a few digits of cold hard cash it's a SwiftUI rewrite that is to blame. (Any1 in the know want to chime in?)
And yeah, it's terrible. Apple doesn't make good apps anymore.
(This is part of why I think electron does so well -- it's not as good as a really good native app [e.g. Sublime Text], but it's way better than the sort of default whatever you'll get doing native. You get a lot of niceness that's built into the web stack.)
While there are missing features (e.g. ability to merge records), I have to say that Passwords.app is worlds ahead of 1Password since their electron rewrite. System Settings is not the best (mostly because the search is broken), but Passwords is sufficiently good that I haven't bothered looking what it's written using, whereas I can immediately tell with Electron.
This is a good thing. Native was always a place where gatekeeping and proprietary crap sprout and thrive.
It can't die soon enough. Doesn't all have to be Electron, but web tech for the win and force everything to the browser unless you'd like to write it twice.
I've been evaluating truly native x-platform GUI frameworks for a while and GPUI[0] from the zed team along with longbridge/gpui-component[1] looks the most promising.
Though I haven't tested it too much other than building small personal tools like a work habit tracker, it's very well documented and looks great. Gave me a good excuse to try the language again as well.
[0]: https://www.gpui.rs/
[1]: https://longbridge.github.io/gpui-component/
I would say that the real reason is because "it works". As simple as that.
The first thing you need when you make something new is making it work, it is much better that it works badly than having something not working at all.
Take for example the Newcomen engine, with an abysmal efficiency of half a percent. You needed 90 times more fuel than an engine today, so it could only be used in the mines were the fuel was.
It worked badly, but it worked. Later came efficiency.
The same happened with locomotives. So bad efficiency at first, but it changed the world.
The first thing AI people had to do is making it work in all OSes. Yeah, it works badly but it works.
We downloaded some Clojure editor made in java to test if we were going to deploy it in our company. It gave us some obscure java error in different OSes like linux or Mac configurations. We discarded it. It did not work.
We have engineers and we can fix those issues but it is not worth it. The people that made this software do not understand basic things.
We have Claude working in hundreds of computers with different OSes. It just works.
They could have done better. They chose the path of least resistance, putting in the least amount of effort, spending the least amount of resources into accomplishing a task.
There's nothing "good" about electron. Hell, there are even easier ways of getting high performance cross platform software out there. Electron was used because it's a default, defacto choice that nobody bothered with even researching or testing if it was the right choice, or even a good choice.
"It just works". A rabid raccoon mashing its face on a keyboard could plausibly produce a shippable electron app. Vibe-bandit development. (This is not a selling point.) People claiming to be software developers should aim to do better.
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.
Let's assume for the moment the developers are doing about the best they can for the goals they're given. The slowness is a product decision, not an engineering problem. They are swimming in cash and could write a check to solve the problem if they cared. Evidence is they have other priorities.
They wrote a React TUI renderer, that’s what they did. Shame…
I understand why, but there is such beauty in the simplicity of ansi.
The company that supposedly is selling that AI can do everything to replace us.
I see no contradiction. You could get replaced by an agent that spews out React TUIs; as if corporate buyers are going to care about the difference!
That’s the hard swallow. End users only care about the UX and it working. They don’t care how succinct your code is. They indirectly care about its performance.
At least it seems like a lot more apps are cross-platform than before. I wouldn't call the native devs lazy for not making a Mac version of their Windows app.
Agreed, yet back in the day we even managed to do that with applications being written in Assembly, in some cases.
Uphill both ways, should be easy for a company doing C compilers with LLMs.
Early games frequently took the approach of inventing an interpreted machine code in which the bulk of the game would be written, with an assembly interpreter that would need to be rewritten for each target IA and modified for the specific peripheral mixes of each target machine.
The approach runs slower than a game written directly in assembly, but the cost to port to different architectures is much lower.
Sort of like Electron trades off native performance and look-and-feel to make multi-platform apps much more achievable.
IMO the OS vendors failed everyone by refusing to even attempt to agree on a common API for UI development, paving the way for web browsers to become the real OS and, ultimately, embedded browsers to be the affordable and practical way to be cross platform.
Except the OS's don't even ship a consistent enough browser engine. (Standards be damned.) So apps ship their own browser over and over again.
Honestly I'm grateful to apps that otherwise wouldn't be available outside of windows.
Realize, though, that just grabbing a frame buffer is not a thing anymore. To render graphics you need GLES support through something like ANGLE, vectors and fonts via Skia, Unicode, etc. A web browser has those things. Any static binary bundling those things is also gonna be pretty large.
And JavaScript is very good at backwards compatibility when you remove the churn of frameworks (unfortunately Electron doesn't guarantee compatibility quite as far back)
And CPUs are only sand powered by electricity.
I do realise the need for abstractions and they do exist, provided there is actually the interest to learn them.
In an age where LLM's start writing applications why would this matter?
I agree, this is clearly an indictment against LLMs. If LLMs and agents were capable they'd 100% write it natively but they realize the current limitations.
Yet another reason to have those LLMs create native applications, should be easy apparently.
I've programmed in every native Windows GUI starting with MFC. Used Delphi too. I've even created MS-DOS TUI apps using Turbo Vision.
Compared to the web stack and Electron, native GUI APIs are complete shit. Both for the programmer, but also for the user.
Reactive UI (in the sense of React, Vue, ...), the greatest innovation in UI programming ever, was made popular by web-people.
Unless you write some ultra-high performance app like a Browser, a CAD app, a music production app, it doesn't make any sense to use native GUIs. Takes longer to program, the result is uglier and with less features. And for those ultra high performance apps you don't use the native UI toolkit anyway, you program your own widgets since the native ones are dog shit and slow.
Don't forget about all the embedded UIs (kiosks, appliances, car infotainment, industrial equipment, ...), those computers are weaker and it makes a ton of sense to use native toolkits there.
They tried to replace our Qt GUI at work in this space with a react based one, the new UI ran like utter shit comparatively, even after a lot of effort was spent on optimisation.
Also, most of the world don't use high end developer laptops. Most of the world is the developing world, where phone apps on low end Android phones reign supreme.
This is such a lazy take.
Electron is very easy to deliver a good quality app for everything but absolute power users.
Yes it's horribly slow but it enables rapid experimentation and it's easy to deliver the wide range of UI integrations you are likely to want in a chat-esq experience.
It’s not even horribly slow. It works fine. It’s just a chat program. It’s the right trade off for the job.
Doing more work for no reason is stupid even if you the have money of a small nation.
The inevitable differences between platforms you get with all native everything isn’t a good user experience, either. Now you need to duplicate your documentation and support pages and have support staff available to address every platform. And what’s the payoff? Saving 80MB of RAM? Gaining milliseconds of latency that Joe Business will never notice as he’s hunt and pecking his way through the interface?
I thought we were done with Electron hate articles. It’s so 2018 to complain about it. It’s like talking about millennials and their skinny jeans. Yawn.
On iOS there isn't always a choice to not build something native. For example, I can't install Navidrome as a PWA because Apple doesn't properly support audio playback for PWAs. I ended up writing a client that suited my listening habits.
To read ePubs, however, I was able to write a PWA leveraging epub.js because no native APIs were required.
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
I have been using Tauri for a macOS app I'm making[1] and it has been great. The app is only 11MB and I've had most of the APIs I'd need.
However, there are still some rough edges that have been annoying to work with. I think for my next project I will actually go back to electron. There are two issues that caused me pain:
1. I can't use Playwright to run e2e tests on the tauri app itself. That's because the webview doesn't expose the Chrome DevTools Protocol, and the tauri-driver [2] does not work on MacOS.
2. Security Scoped Resources aren't fully implemented which means if a user gets the app through the app store the app won't be able to remember file permissions between runs [3]. It's not too much of an issue since I probably won't release it on the app store, but still annoying.
But I hope Tauri continues to grow and we start seeing apps use it more.
[1] https://tidyfox.app/
[2] https://v2.tauri.app/develop/tests/webdriver/
[3] https://github.com/tauri-apps/tauri/issues/3716
+1 for Tauri, I've been using it for my recent vibe-coded experimental apps. Making rust the "center of gravity" for the app lets me use the best of all worlds:
- declarative-ish UI in typescript with react
- rust backend for performance-sensitive operations
- I can run a python sidecar, bundled with the app, that lets me use python libraries if I need it
If I can and it makes sense to, I'll pull functionality into rust progressively, but this give me a ton of flexibility and lets me use the best parts of each language/platform.
Its fast too and doesn't use a ton of memory like electron apps do.
Also, Rust's strong and strict type system keeps Claude honest. It seems as if the big LLM models have trained on a lot of poorly written TypeScript because they tend to use type assertions such as `as any` and eslint disable comments.
I had to add strict ESLint and TypeScript rules to keep guardrails on the coding agents.
I added a list of known Extism implementers to my comment above, to take inspiration from should Extism be attractive to consider for you.
I find it a bit odd how much people talk up the Rust aspect of Tauri. For most cases you'll be writing a Typescript frontend and relying on boilerplate Rust + plugins for the backend. And I'd think most of the target audience would see that as a good thing.
I working on a project using tauri with htmx. I know a bit uncommon. But the backend part use axum and htmx. No Js/Ts UI. It's fast, reliable and it work well. Plus its easy to share/reuse the lib with the server/web.
I am considering a Tauri app, but still wondering about architecture design choices, which the docs are sparse about. For instance the Web-side may constitute a more full-blown, say NextJS, webapp. And include the database persistance, say SQLite based, on the web side too, closest to the webapp. That goes against the sandboxing (and best-practice likely), where all platform-related side effects are dealt with Platform-side, implemented in Rust code. I wonder if it is a valid choice. There is a trade-off in more ease of use and straightforwardness vs. stricter sandboxing.
At least with Tauri it's easy to both make the choice and change it later if you want to. I think the docs are sparse because it's your decision to make. I've done it both ways and there are pros and cons. If you use the sqlite plugin and write the actual statements on the JS side then you don't need to worry about the JS<->Rust interface and sharing types. Easier to just get going. If you write your own interface then you probably want to generate TS types from Rust. I think a big advantage to the Rust interface way is that it makes it easier to have the web side be dual purpose with the same code running on the web and in Tauri - the only difference being whether it invokes a tauri call or an API call.
Thanks for that feedback. Makes me feel more comfortable with the option I have in mind.
I use something similar to Tauri called Wails: https://wails.io/ that's Go-based.
Looks cool, but the phrase 'build applications with the flexibility and power of go' made me chuckle. Least damn flexible language in this whole space.
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.
> LLM-driven development could land on a safer language
Why does an LLM need to produce human readable code at all? Especially in a language optimized around preventing humans from making human mistakes. For now, sure, we're in the transitional period, but in the long run? Why?
From my post at https://jerf.org/iri/post/2026/what_value_code_in_ai_era/ , in a footnote:
"It has been lost in AI money-grabbing frenzy but a few years ago we were talking a lot about AIs being “legible”, that they could explain their actions in human-comprehensible terms. “Running code we can examine” is the highest grade of legibility any AI system has produced to date. We should not give that away.
"We will, of course. The Number Must Go Up. We aren’t very good at this sort of thinking.
"But we shouldn’t."
Because the traits that make code easy for LLMs to work on are the same that make it ideal for humans: predictable patterns, clearly named functions and variables, one canonical way to accomplish a task, logical separation of concerns, clear separation of layers of abstraction, etc. Ultimately human readability costs very little.
I can't even imagine what "next token prediction" would look like generating x86 asm. Feels like 300 buffer overflows wearing a trench-coat, honestly.
It'd just run out of tokens
> For now, sure, we're in the transitional period, but in the long run? Why?
Assuming that after the transitional period it will still be humans working with ai tools to build things where humans actually add value to the process. Will the human+ai where the ai can explain what the ai built in detail and the human leverages that to build something better, be more productive that the human+ai where the human does not leverage those details?
That 'explanation' will be/can act as the human readable code or the equivalent. It does not need to be any coding language we know today however. The languages we have today are already abstractions and generalizations over architectures, OSs, etc and that 'explanation' will be different but in the same vein.
So humans can verify that the code is behaving in the interests of humanity.
Well, IMO there's not much reason for an LLM to be trained to produce machine language, nor a functional binary blob appearing fully-formed from its head.
If you take your question and look into the future, you might consider the existence of an LLM specifically trained to take high-level language inputs and produce machine code. Well, we already have that technology: we call it a compiler. Compilers exist, are (frequently) deterministic, and are generally exceedingly good at their job. Leaving this behind in favor of a complete English -> binary blob black box doesn't make much sense to me, logically or economically.
I also think there is utility in humans being able to read the generated output. At the end of the day, we're the conscious ones here, we're the ones operating in meatspace, and we're driving the goals, outputs, etc. Reading and understanding the building blocks of what's driving our lives feels like a good thing to me. (I don't have many well-articulated thoughts about the concept of singularity, so I leave that to others to contemplate.)
LLMs are better at dealing with human-readable code on their own too
For one thing, because it would be trained on human readable code.
I’ve only built some basic CRUD-type apps in SwiftUI, but I thought it was pretty nice. The APIs seem well thought-out, I needed less code than I would have to do the same thing in React, and the default styling looked quite professional.
Of course, the React ecosystem and community is enormous. I bet if I was building something complex, I would have gotten frustrated building it all from scratch in SwiftUI when I could just reach for a React component library.
Somehow, a CAD program, a 3D editor, a video editor, broadcasting software, a circuit simulation package, etc are all native applications with thousands of features each - yet native development has nothing to offer?
No it's because LLMs aren't that good yet.
"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.
Having said (read) that, I am surprised there is still no official Claude Desktop app for Linux. :'(
But on the other hand the claude app is garbage… https://github.com/anthropics/claude-code/issues/22543 obviously native apps can be garbage too, but I must say electron apps have a surprisingly high incidence of terrible performance issues, unsure if it’s a correlation or causation issue
Use Claude to create native apps. Done.
It can even create a beautiful Java Swing apps.
I love Claude but both the desktop and the web apps are incredibly janky when compared with their OpenAI counterparts (I won’t even comment on Gemini’s because it’s also incredibly broken and unreliable).
Start times are atrocious, long conversations literally break rendering (and I’m using the desktop app on a MacBook Pro with an M3 Pro CPU and 36 GB of RAM so an electron app shouldn’t feel so janky so frequently, right?).
IMHO they just don’t care right now (and I get it from their perspective) but I’m pretty sure there’s a lot of low hanging fruit they could fix to make the experience 5x or even 10x smoother. Claude Code (TUI) is also another memory hog and I’ve even had Ghostty literally crash with enough open sessions.
Fortunately Anthropic models are also incredibly so at least I’ve been able to speedrun my own desktop client using Tauri and fix many of the issues I encounter every day. I might release it at some point.
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.
The rise of Electron was purely because you can share the codebase for real with the web app (for lots of apps it is their main focus) and get cross-platform support for free.
Native apps are not bad to develop when using Swift or C#, they are nice to use and their UI frameworks are fine, it's just that it requires a separate team. With Electron you need much less, simple as that.
> As for the rest: minor variations in traffic light positioning and corner radii are topical but hardly indicators of decaying platorms.
I think it shows how important the platform itself is to the company. The system settings app on macOS is literally slow to change the topic (the detail page is updated like ~500ms after clicking).
I personally love to develop desktop apps but business-wise they rarely make sense these days.
> Disagree. The "rise of Electron" is due to the ubiquity of the JS/HTML/CSS/Node stack, and many junior developers knowing nothing else.
with all due respect - hard disagree. in what place on Earth to Junior Devs make these types of decisions?? Or decision makers going “we got these Juniors that know JS so it is what is…”
I don't believe they were implying they would make the decision. It's expensive to have your team learn new skills from scratch, and management won't want to pay for that if they don't have to.
This is indeed what I meant. Thanks for stating it with more clarity than I was able to.
I have been coding for 30 years now and I have never encountered a technical decision like choosing technology (e.g. Electron) for anything important to the company being made with "oh, we must use X because so and so knows X"
Maybe if there was a toss-up between X and Y or something like that but to flat-out pick Electron because you have people that knows JS is madness
I'm thirty+ years in too, and it happens all the time - particularly in smaller operations. Resourcing constraints, disinclination to provide training, tight deadlines, etc.
so interesting!! and scary :)
With regards to "we've lost native" isn't local-first the opportunity to bring it back in a paradigm shift that deals a blow to both the browser and cloud vendor hegemonies?
https://lofi.so/
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.
Ha
Hahaha
Hahahahaha
I'd still take native KDE/Plasma apps over Electron any day. Just the performance and memory usage alone is worth it.
Sublime Text feels so much snappier than VSCode, for another example. And I can leave it running for weeks without it leaking memory.
With today's processors and speeds, there really is no difference in performance of these Electron apps vs Native and anyone disagreeing just dislikes the JS ecosystem
Based on "anyone disagreeing just dislikes the JS ecosystem", I feel like you might not want to grace me with a response, but I disagree /somewhat/.
Electron and web technology generally is certainly more performant than it once was, and I think people do malign Electron specifically a bit too much. VS Code continues to be the anti-example. It's always rather surprising it's just a web view, even on lower end hardware. (A several year old raspberry pi for example)
(Please note, I said "surprising it's just a web view", not "it's more performant than it could be if built differently".)
I think the main difference people tend to experience is a lack of care. I would say, for reasons I am NOT sure are causal, electron apps do seem to tend towards worse experiences on average in my experience. I think on the web, a quick flash of unstyled content or that ghost of the element you accidentally dragged instead of clicked are seen as just minor issues, because they're expectations of the web. If things go REALLY wrong, I have a whole rock solid toolbar above the app that lets me refresh if I think I'm in some infinite loop, or the URL bar I can look at if I'm not sure what page I was just redirected to. The back button promises to return me to where I was before. The browser is caging-in applications for me, so it's fine if they're a bit rowdy.
But using an application that is pretending to NOT be a web browser, seeing any web-quirk feels like I'm staring at rusted rebar in a cracked concrete bridge. The bridge still works, but now I'm aware of the internals of it and maybe that makes me feel a little more uneasy about standing on it. There is no back button if something goes wrong, and if there is, the app itself is rendering it. It's of course possible to hide that reality from me, but you need to care about sealing up all the cracks that let me see the rowdy internals.
To be fair, maybe that's just me that feels that way. And I do rather like the JS ecosystem.
I disagree because yes I dislike the whole JS ecosystem and the language itself. But also because Electron apps in general are resource monsters and while some are better than the others, Claude Desktop is definitely not one of them. Hell even their website will crash on Firefox very often.
hard disagree, Zed, for example, feels miles better than VS Code
The thing people miss is isn't not that there aren't downsides (power, memory, disk size, dependency ecosystem size etc etc) it's that they're still completely outweighed by the upsides of write-once-ship-all for authors.
How about power, and battery capacity?
also memory footprint, jank, and the pitch-black dependency forest.
I probably drink more web kool aid than the next guy but this is just not true.
Electron apps dealing with more than a small handful of data rapidly start to show poor frame timing and input lag.
Cannot agree more. Whenever I am making a decision like picking tech at work I always assume everyone who will use it has new $5k MBPs.
all the kids in schools with their chromebooks and whatnots? - oh well, they can tell their parents to get you an MBP :)
Claude is slow on a $5k MBP too.
Everyone has a 1000Mbps fibre connection too with 3ms latency. If not, well, they need to try harder at not being poor
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.
>> cross platform UI framework
How about Java Swing? It's already battle tested and deployed everywhere you have Java.
When I complain about a lack of “native” software I pretty much always mean the platform-provided defaults. Not some cross-plaform UI toolkit that happens to be “native” code. Most apps that I see using QT on Mac or whatever would provably be better as Tauri apps.
Respectfully: skill issue. My employer ships software native for Windows, Mac, iOS and Android. Different codebases for all (though they share a lot of common stuff), all maintained by a shockingly small team.
It’s absolutely achievable if you give a shit about your products and I’m long over hearing the bevy of usual fucking excuses from software houses often magnitudes larger than us who struggle to even keep their electron shit working correctly.
Native is shorthand for "integrated into the platform". Lowest-common-denominator stuff that Electron gives feels correct nowhere (looking at you, Slack). The very best cross-platform applications implement their UI using the native platform idioms on the native platform technologies, and share the core of their logic. The current best example I have is Ghostty which feels perfectly at home on either macOS or Linux.
10 days ago: https://news.ycombinator.com/item?id=47104973
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.
You've basically described Flutter and Jetpack compose(for desktop). The problem really does turn into effort to pay off, even if we stayed with JS and the rendering engine, figured out a way to compile JS into native code and completely stripping all of the unused functionality and doing the same thing with the rendering engine. All of that would need to be made, it's not like electron apps literally crash you machine. You have metrics, hundreds of millions of devices running electron apps at a daily basis. Unless you make your own company, I don't think anyone can convince their leadership to take such a decision.
I'm not arguing for actually doing this, I'm just suggesting Claude's limitations are actually an issue (contrary to what the article asserts).
This wouldn't be an issue if they allowed 3rd party apps or priced their API competitively with their subscriptions. Free software normally fixes these types of problems but is prevented in this case.
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.
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...
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.
What's the advantage of their Electron apps vs using the web? I get that in theory you can use native-only pieces that a browser doesn't support, but in practice a lot of Electron apps are literally the website.
Apple/Google could easily make web apps native if they wanted
Clicks link, goes to blog site
My eyes! The goggles, they do nothing!
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.
Conversely, an app using native toolkits (at least the Windows ones) will have better chances of running fine under Wine. I've recently had the (dis)pleasure of trying to run some .Net monstruosity with Wine, and oh my got did it not work for obscure reasons.
But overall yeah, from a compatibility perspective, nothing beats Electron. I'm not sure we'd ever get an official Discord client on Linux otherwise.
Now if only Wine would work natively on Android
More like a skill issue, than 'losing native'.
I'm reposting this I saved from Hacker News user gjsman-1000 because it's so good and so true.
https://news.ycombinator.com/item?id=36060678
I really doubt that at this point. Developers have learned that everything Microsoft says to do for Windows, since 2012, will be garbage within a few years. Guaranteed.
Learned Silverlight for Windows Phone development? Too bad, it's UWP now. And the XAML is incompatible.
Learned WinRT for Windows 8/8.1 app development? Too bad, it's UWP now. And the XAML is incompatible.
Packaged your App for APPX? Too bad, it's MSIX now.
You learned how to develop UWP apps? Too bad, the User Interface layer has been ripped out of UWP, it's now called WinUI 3, and it doesn't even run on UWP. Better port your UWP app back to Win32 now, I guess. Why did you even learn UWP again?
You went and learned WinUI 3 like we recommended? Well, unlike WinUI 2, it doesn't have a visual designer, and it doesn't have input validation, or a bunch of other WinUI 2 features. So, depending on what your app needs, you might have a mix of UWP and Win32, because WinUI 2 is UWP-exclusive and WinUI 3 is Win32-exclusive and neither has all the features of the other. Progress!
You built your Windows 8 app with WinJS? Well, sucks to be you, rewrite it in entirety, WinJS was scrapped.
You ported your app from iOS with Project Islandwood? Well, again, that sucks. It was brilliant, it made pulling apps over from iOS much easier, but it's dead. Rewrite!
You decided to hang it all, develop for good old WPF, but wanted to use the Ink Controls from UWP? Great, we developed a scheme for that called XAML Islands which made so you could have some of the best UWP controls in your old app. Then we released WinUI 3, completely broke it, and made it so complicated nobody can figure it out. So broken; even the Windows Team doesn't use it and is writing the modern Windows components for File Explorer with the old version.
But of course, that would require WinUI 2, for UWP, inside Win32 which is the main feature of the broken WinUI 3; which means that the Windows Team has a bastardized version of XAML Islands for their own use that nobody else has (literally), to modernize the taskbar and File Explorer and built-in apps like Paint, that nobody who wants to emulate them can borrow. Their apps don't look modern and their users complain? Suckers, go learn WinUI 3, even though our own teams couldn't figure it out.
You wanted your app on the Microsoft Store? Well, good news, package it together with this obtuse script that requires 30 command-line arguments, perfect file path formats, and a Windows 10 Pro License! Oh, you didn't do that? Do it 5 years later with MSIX and a GUI this time! Oh, you didn't do that? Forget the packaging, just submit a URL to your file download location. Anyone who bothered with the packaging wasted hours for no real purpose.
Did I mention Xamarin? A XAML dialect of its own, that supports all platforms. But it runs on Mono instead of the authentic .NET, so you'd better... work around the quirks. Also it's called MAUI now, and runs on .NET now. But that might break a few things so hang around for over a year's worth of delays. We'll get it running for sure!
Oh, and don't forget about ARM! The first attempt to get everyone to support ARM was in 2012 with a Windows version called... No, no, no. Go past this. Pass this part. In fact, never play this again. (If you want to imagine pain, imagine running Windows and Microsoft Office on a ARM CPU that came three generations before the Tegra X1 in the Nintendo Switch. Surface RT ended with a $900M write-off.)
And so on...
Or, you could just ignore everything, create a Windows Forms (22 years strong) or WPF app (17 years strong), and continue business like usual. Add in DevExpress or Telerik controls and you are developing at the speed of light. And if you need a fancier UI, use Avalonia, Electron, React, or Flutter.
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.
> with the same buttons and corner radius as other apps on the system
I just checked: No, the corner radius is different. I'm personally not very bothered by that, but it's just empirically true.
> Electron is a native wrapper for web content. The wrapper is still native.
In my view, the problem isn't that it's a wrapper, but rather that it's that it's a bad wrapper of a bad runtime (i.e. the incredibly bloated JS/web stack).
> I just checked: No, the corner radius is different.
It may depend on which SDK version the developer uses.
UIKit etc never made sense to me after years, CSS also didn't make sense, but right out of the box I understood React. And with hooks, it's way less boilerplate than the UIKit ways.
Separate from that, Apple doesn't seem to mind breaking native macOS apps, to the point where most devs treat native code like a liability on Mac but ok on Windows.
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?
They did something to Settings after MacOS Monterey that made it very slow. I miss the snappiness of the old app!
I don't know for a fact, but I'd bet a few digits of cold hard cash it's a SwiftUI rewrite that is to blame. (Any1 in the know want to chime in?)
And yeah, it's terrible. Apple doesn't make good apps anymore.
(This is part of why I think electron does so well -- it's not as good as a really good native app [e.g. Sublime Text], but it's way better than the sort of default whatever you'll get doing native. You get a lot of niceness that's built into the web stack.)
Well, perhaps it has something to do with the fact that they started using webviews for stuff like system UI: https://blog.jim-nielsen.com/2022/inspecting-web-views-in-ma...
While there are missing features (e.g. ability to merge records), I have to say that Passwords.app is worlds ahead of 1Password since their electron rewrite. System Settings is not the best (mostly because the search is broken), but Passwords is sufficiently good that I haven't bothered looking what it's written using, whereas I can immediately tell with Electron.
System Settings is so slow for the amount of contents it has that I have to say it is probably the worst offender per content capita
Hard agree on 1Password. After Slack it's probably the worst Electron app on my Mac.
Codex cli rust /thread
But the Codex app is Electron based...
Isn't native just the CLI?
This is a good thing. Native was always a place where gatekeeping and proprietary crap sprout and thrive.
It can't die soon enough. Doesn't all have to be Electron, but web tech for the win and force everything to the browser unless you'd like to write it twice.