Claude is an Electron App because we’ve lost native
73 points by bhoot
73 points by bhoot
Why is losing native a bad thing?
Windows and macOS are proprietary operating systems and so are their native APIs. Their native APIs are defined by their canonical OS-provided implementations with all their quirks, versus a free and open standard maintained by a consortium/working group with multiple stakeholders. Software written against those native APIs are not cross-platform, especially the more they take advantage of platform-specific APIs, and perpetuates the lock-in effects of those operating systems (and in the case of macOS, MacBook hardware too).
I think Electron (or Web-on-Desktop and -on-Mobile) is one of the best things that happened in the free software movement so I don't know why people are so critical of it. Genuinely curious to hear their arguments besides the look & feel of native apps (which as the author argues is also now gone thanks to multitude of different/competing APIs).
Performance (nodejs). Security (nodejs). Trading one monopoly for another (Google). Disk/RAM usage (node_modules/).
Security (nodejs)
I presume you are referring to supply-chain issues in the JS ecosystem which is fair, but on the flip side JS has none of the memory safety issues that C/C++ programs have. I realise that C# and Swift solves that too, though not sure what’s the alternative on Linux.
Trading one monopoly for another (Google)
It’s true that Google has monopolistic influence over Web standards through Chrome but Web is still a far more open platform than the others in my opinion so I don’t think this fair.
"than the others" in this case is GTK, Qt, Tk, imgui, Cocoa, Winforms or other?
There's a fair bit in this space.
You can pretty easily build web apps for desktop without Electron (and thus Chrome/Node) specifically.
I've tried to do this a few times, but I've always found it challenging and had disappointing results. What easy approaches would you recommend?
While I haven't used it myself, I hear decent things about tauri.
Tauri is actually "electron-but-preinstalled", also known as WebView, which is Chromium in Windows (I guess it is Safari on Mac).
It's webkit on macos and linux. And yeah, you can use WebView without Tauri as well--it has decent bindings for most programming languages, and it's not too hard (well, as far as cross platform GUI apps go, anyway)
Anything that uses WebView works pretty well. It leaves a lot for the developer to figure out (mostly determining where to draw the line between client and server and how to make a native package for each platform). It was by far the least bad option for cross platform app development.
Are you claiming each OS has a perfectly great independent HTML/CSS/JS implementation but for some unknown reason everybody is using Chrome?
Pretty much, yes. It's not "some unknown reason", it's because Chrome is the popular browser and they don't share the parent's concern about browser monopolies or optimally performant programming languages.
It's a bad thing because in practice, it's not a like-for-like replacement for native. Fault lies with Electron and developers using Electron. One example I've seen is accessibility. This has evolved but it's not equivalent to native. Electron takes a few steps forward, but they don't fully catch up. Then it's on devs using Electron to update versions or make changes to adopt capabilities in order to improve. Devs can't keep up in practice so there is lag. Sometimes they never complete the work for their app.
A subset of developers complain a lot because they know that the support comes for free, or much less effort, with native development. The pattern with accessibility repeats with everything from keyboard shortcuts to context menus. Those around the Electron development community, or any non-native development community, recognize the gaps. As you get further from those communities there is less recognition of the issues because the devs using Electron often don't have that much desktop experience. This is important to recognize because it affects how they can engage with the complaining devs who understand native (and have possibly dealt with non-native toolkits.)
That is a pretty narrow definition of native though. I think GTK has offered a "native" experience that has delivered the performance and consistency the article is looking for for 25+ years. There's decisions the project has made that some people disagree with but they haven't been blown around by the UI winds the way Windows and macOS have. They have official bindings for various languages so you aren't limited to C as an application implementation language.
I don't think macOS, Windows or KDE users would consider a GTK app to feel "native".
Surely not for some definition of the term. However I think they would find it hard to argue that GTK apps are slow (as a group), inconsistent, or change appearance too much. Regardless of the term used, those were the concerns of the article.
Then there’re looks and consistency. Some time ago, maybe in the late 90s and 2000s, native was ahead. It used to look good, it was consistent, and it all actually worked: the more apps used native look and feel, the better user experience was across apps (which we used to call programs).
The article acknowledges the idea that native apps used to be more consistent, he just argues they aren't anymore.
Performance and the feeling of not wasting resources. TUI applications. Blender. DAWs. Web servers.
I'm surprised you bring up the TUI. I actually feel like the TUI is a big blind spot because many of the same people that like TUI applications seem to dislike Electron. But what, really, is a TUI? We're emitting VT100 ANSI codes through a pipe to a terminal emulator which translates these ANSI codes into rendering primitives which actually render the TUI. So we're working with a library atop an emulator atop the actual graphics processing pipeline. It may be fewer abstractions than Electron (which depends on Web stacks) and is a user level as opposed to kernel level abstraction (like the PTY) but otherwise is similarly a stack of abstractions far removed from native graphics performance.
Right on, this I something that just keeps killing me. Why are we still using these abstractions? I used to literally make and run the RS232 cables that were needed in the real-tty world and I can’t for the life of my understand why we need pty in 2026. Is it just so we can run ssh?
The TUI itself is a great way to use a computer but why we have to serialise what is essentially a 2-dimensional array of bytes into an archaic protocol with dedicated drivers only to have it deserialise again on the other side with literally no gain… it’s baffling to me.
It makes me want to go and write something just to prove that we don’t need this crazy stuff.
The why is of course because there is nearly 50 years of software written for ANSI-style terminals, and rewriting it all to use some other display protocol is too large an undertaking.
For 25 years Microsoft tried to do it differently. The Windows NT console didn't use ANSI escape sequences, but rather provided an API for interacting with it. But all this meant was that for 25 years Windows NT was incompatible with the way TUI software was written everywhere else, so in 2018 they gave up. The old console APIs are deprecated and ANSI escape squences are the way forward. The Windows Terminal aims for compatibility with xterm, DECs VT525, and supports a selection of features from DECs VT340 graphics terminal. Those old Windows NT console APIs are now translated into ANSI escape sequences.
Their solution wasn't very good as it didn't remote very well. We could probably design a much better protocol today but it would still probably need to be serializable for remote purposes.
I think because most of the benefits of a TUI are that compatibility with an archaic protocol. If you were designing a TUI from scratch for the modern era, you'd want so many features (mouse interaction, variable size fonts, images, etc) that you'd basically end up with a GUI by any other name. And if I've got the option of a proper GUI, I'd usually rather take that.
So that middle ground of "TUI, but with a proper protocol" always sounds appealing, but in practice there's not much value to it. You lose out on the compatibility with existing terminals, but you also don't get the UX or DX of, say, Electron.
I estimate that the amount of APIs you can use in a browser vs. natively on Windows is around 2% (the shiny part). This 2% has gradually grown from 0.1% over the years with the rise of Electron. Electron is a symptom of bigcos being unable to work together to create a standard for building UIs. I feel Microsoft has even given up on Windows ever having a consistent and modern UI framework. So here we are, left on the roadside with Chromium - good luck. Everyone is building the "minimize-maximize-close" controls by hand; you can find a diverse experience similar to what Tonsky showed for Mac.
Of course, you can unlock 100% native API with Tauri (Rust) or Wails (Go), but users will still suffer from inconsistent UI, performance penalties, and version drift (because now you've outsourced the Chromium version to the OS - now out of your control - exposing you to various bug reports you can't even reproduce). They also have to tolerate native OS dialogs and controls showing up here and there (file save dialogs, etc.).
I have never seen a pleasant experience with these so-called "cross-platform UI frameworks": not because they are not cross-platform, but because they fail to implement nuances the OSs have had for 20 years. These are not easy to fill, I admit.
I feel Microsoft has even given up on Windows ever having a consistent and modern UI framework
Unfortunately this is far from a new problem. Since the release of .net in 2002 it feels like Microsoft just wheels out a new UI framework every few years only to be abandoned when they change direction or get distracted by some new shiny thing. So I don't really blame developers for just ignoring whatever Microsoft is doing and using something else.
I have never seen a pleasant experience with these so-called "cross-platform UI frameworks": not because they are not cross-platform, but because they fail to implement nuances the OSs have had for 20 years. These are not easy to fill, I admit.
I've found stuff built with Qt Widgets tends to blend in well enough on Windows - at least as much as anything can blend in there these days.
I searched my apps for a Qt-based one and found Wireshark, it took me about 30 seconds to find a "nuance": ctrl+pageup and ctrl+pagedown is not changing the active tab on a tabcontrol :)
I spent some time trying to port an Electron app to FreeBSD, then gave up. This was years ago; things are better now as Electron itself has been ported by people way more patient and tolerant than me.
At the time my dislike of it included:
Very poorly-written code. Rather than detecting OS capabilities, it was littered with checks for the specific OS. So in psuedocode, instead of saying if posix_thing then foo, it was if linux then foo ... which meant that adding FreeBSD support wasn't just defining what capabilities FreeBSD has, it was adding a bazillion small patches like if linux || freebsd, except where that wasn't true. Boo. I was fixing up C code that did this twenty-six years ago, very surprised and sad to see it still being done today.
Build dependencies. ALL THE DEPENDENCIES. So many libraries, and so many more as transitive dependencies. All for a relatively simple test harness UI.
Development performance. I could build and run native OSs, including on notoriously big platforms like Common Lisp, far more quickly than I could with Electron. Developing for native on my X220 was a breeze; it was far too slow for pleasant Electron work.
Runtime dependencies. The final straw, for me, was Electron complaining it didn't have privileges to use the right 3D acceleration API. Again, for a SIMPLE TEST HARNESS UI.
Edit: yes I'm still peeved about this, years later. I really did put some effort into Electron, and it was one of those experiences where the more I learned, the more I disliked it. Quite the opposite to some other platforms and systems I've used.
Edit: griping about dependencies isn't purely old man shouting at clouds ;) ... every one is itself a potential porting job because a lot of developers make very Linux-y shaped assumptions about their operating environments.
I once had to make a very small enhancement to Electron; probably less than 100 lines of code, but building it was so incredibly painful; the first clean-slate build took more than 24 hours.
defined by their canonical OS-provided implementations with all their quirks, versus a free and open standard maintained by a consortium/working group with multiple stakeholders.
Quirks are good, it's the computing equivalent of competition. Platforms shouldn't be blocked on consortiums and working groups to make progress and innovate.
Take something as foundational to programs as i/o. We have a standard API for async i/o, it's POSIX select/poll. In practice, there are three different i/o interfaces (kqueue, iocp, and io_uring) that real applications wind up using instead of the standard interface.
Also, standards usually describe and canonicalize existing practice rather than design what that practice should be from first principles. You have to start with the proprietary/unique quirks before you can establish the standard interface - and moving too early causes as much of a problem as not standardizing at all, because a bad standard just gets ignored.
I want unique platforms with unique capabilities and I want the applications on those platforms to take advantage of them. Web for the most part offers a least common denominator option that every platform must support. But native platforms are capable of so much more (or could be).
For example, I am a happy Apple ecosystem user. My whole family is just all-in. I'm going to use them as an example.
I love the magic that is AirPods just... working. The other night my wife fell asleep on the couch and I was in a rental using an Apple TV that wasn't mine and I wondered... what happens if I put this AirPod in my ear? The Apple TV prompted me, paused playback when I said yes, asked for a code pushed to my iPhone, and magically started playing the TV audio through my AirPods. I never paired it. I never signed into the Apple TV. I'd never been in that bed before. Hell. Fucking. Yeah!
I hear AirPods kind of suck outside of the Apple ecosystem. I don't know, but also... fine? That's why other headphones exist. You can choose. I choose mine because they integrate seamlessly through this beautiful walled garden. They shouldn't bend to other ecosystems just because they use some standard transport layer mostly.
Or, for stuff that applications can opt into: iCloud syncing. When an application uses iCloud for syncing data or behaviors across devices, I know that my data is staying local, its being secured by Apple (whom I trust, at least much moreso than the average dev), and that its sandboxed. I want MANY MORE applications to integrate with iCloud.
Another example: Apple Shortcuts. I use them to automate all sorts of stuff! Applications can advertise their own automations you can connect. And, like above, they just magically sync across your devices. When I get a new Mac, there it is. I can even trigger Mac shortcuts from my iPhone and vice versa (via some tricks, but still). Awesome.
Browsers don't let you do this, because browsers have to yield to what everyone running the browser can do. Browers are great, they have their place, but I don't think they should full-scale replace native and I don't think it's a clear cut celebration in either direction.
I want more unapologetically non-least-common-denominator applications. I want more applications to say "oh, you don't have our platform? too bad." (for any platform, not just Apple of course).
Tonsky here hits the nail on the head: native can and should offer so much more than web, but it is definitely falling short.
I think Electron (or Web-on-Desktop and -on-Mobile) is one of the best things that happened in the free software movement so I don't know why people are so critical of it.
I had bad reactions to Electron/Tauri for most of the 2010s, and still have some distaste, but per the points in the article, I think I've softened on them as it's become pretty clear that "native" has less and less to offer. In the 2010s:
There was more penalty for increased resource use. If Slack took 2-3GB of memory, you felt it harder.
Web capabilities were less fleshed out. Things like location detection, camera access, files and persistent on-client storage were a lot harder.
The UIs were worse too. Web design has improved in the last decade with CSS improvements and adoption. We've also learned to create experiences that are more responsive (e.g. fewer SPA whole screen resets, placeholder spinners and blurry graphics instead of layout changes when images load...) and we've had another decade of tolerating shitty web experiences so they're a less novel pain when we do encounter them.
Permissions, sandboxing, and the norms around data. I used to use Slack and Linear in browser tabs because I trusted the browser sandbox over an executable that provided the same functionality but I'd "installed" with native capabilities. This might have been just woo on my part, idk.
Desktop nostalgia was fresher, and the industry was more concentrated with Gen X/Millenials who grew up with desktops and watched the web emerge.
These days the computers have hundreds of gigs of memory, browsers are a lot better, good native is further and further away, and the norms around data and privacy have shifted considerably, especially as all the new grads and Zoomers have entered the workforce and shifted the tastes with it. None of the previous criticisms are any more wrong per se, but I think most people feel there are bigger fish to fry. I still have abstract and far-off issues with this development, but I don't care care about them, and view it more as a symptom than as a cause.
These days the computers have hundreds of gigs of memory
Are you being hyperbolic? I certainly don’t have hundreds of GB of RAM, in fact i regularly restart my browser to regain some RAM for useful things.
ahaha I'm checking back in to see many people are hitting me for this. I suppose I should've said "many people (or at any rate, many more people) are running computers with over a hundred gigs of memory." I l built a machine last year before the memory crisis with over a hundred, and most of my friends at extremely well-capitalized startups are given computers with the memory maxed out (I know this isn't common, they're just drinking the AI juice).
Regardless, I feel like the impact of a few gigs of memory use is less than it was a decade ago.
Apple only recently bumped their lowest RAM to 16 GB, which I'd guess is what "most" "normal" users are going to buy. I'm sure there's stats somewhere…
https://store.steampowered.com/hwsurvey/ram/
Took a look at the Steam survey, and the most common RAM size for gamers is 32 GB.
But I find it amusing that the "more than 64 GB" percent is 0.37% - consider yourself a minority! :P
Huh. Both my desktop (custom Ryzen build) and laptop (Framework 13 Ryzen) have 64GiB. I hadn't realised just how unusual that is.
I suppose I should've said "many people"
most of my friends at extremely well-capitalized startups
"Friends at extremely well-capitalized startups" are a tiny, tiny minority of people.
Computers have hundreds of gigs of memory? Are beefy $2k developer machines the only computers we care about now? The largest amount of memory I've ever had on a computer was 16GB, and the laptop I'm writing this from is 8GB (soldered, so I can't upgrade it). I suspect most students and people from less privileged positions (not as well off, working on a work-issued laptop, from less-developed areas, etc) are in a similar place.
fwiw, I avoid Electron apps like the plague personally, which is a huge reason why I don't use Discord (beyond the age verification controversies). 8GB, supplemented by swap, is otherwise quite sufficient for what I do, though I must sometimes restart Firefox just to clear out some unused memory.
Right, and I’m appalled we think Electron is remotely comparable to what a native developer can do if they care about software quality.
Look at File Pilot (2MB) or my own Terminal Click (5MB) and tell me with a straight face Electron is competitive? I never thought Lobsters of all places would be carrying water for bloated tech.
My Windows app is less than 1MB and users say that they chose it because of its speed. IMHO, we did not "lost native". In addition to performance and deep OS integration, users may want to use native apps because they want to keep their data private.
File Pilot still has zero accessibility for blind people using screen readers. With Electron (or, if you prefer, Tauri or something else based on the OS-provided browser engine), one might get some controls that are implemented as divs with no meaningful semantics, but one is at least unlikely to get a completely inaccessible UI where one can't even read the text.
Discord especially annoys me - nothing it does warrants routinely using a gig of RAM. I bet if it was written as a native app it would use at least an order of magnitude less RAM and probably perform better too without loosing any functionality. And spotify is an even worse memory pig given what its supposed to do.
I have a feeling the same app made by the same org would have similar issues regardless of what tech they use.
Computers have hundreds of gigs of memory?
ahaha sorry, I misspoke, I should have said something like "many more people are running machines with over a hundred gigs of memory."
Are beefy $2k developer machines the only computers we care about now?
I don't know where you get this implication from what I wrote, though. I personally wish this wasn't the case and that we cared about resource use, and the "VC-backed tech ecosystem only tests or cares about top-end machines, mobile or desktop" is a problem that we've had since the early 2010s.
These days the computers have hundreds of gigs of memory
I'm very surprised to hear this. I was under the impression that 16GB of RAM was still a large amount, an impression I got from looking at the options for a new computer this year. Do you have any references for how much memory personal computers have currently?
I suspect there’s also an element of “the 2010s saw a glut of fresh graduates from code academy who were thrust into frontend development and made a mess, and people blamed the web generally”. I’m not intending to throw shade at code academy graduates—frontend development is complex and our industry treated it like it was easy. Now that those devs have a decade of experience under their belts and there is much less emphasis on code academy, things are maturing.
If it makes you feel better considering the dogpile, I agree. I’m having the same issue with Sailfish OS where so long as you have web app that targets Fx 91 ESR (sadly), I can get an experience. I’m not convinced long-term that the Android compatibility layer thing is going to continue working given the changes to the Play Store & Google/Apple duopoly stranglehold against FOSS (not just Apple/Microsoft on PCs). I press doubt on a seeing a real Sailfish native uptake—or a good turnaround for small-form-factor-optimized native Linux apps. The web has been web-first+responsive for a decade now which covers a lot most platforms & form factors (even KaiOS, the featurephone OS). It’s not ideal or as performant, but with limited resources, the web gets you the most reach & given the ubiquity + de facto requirement of some web engine, this covers new/emerging OSs that aren’t even yet known about. It also helps that you don’t have to ‘install’ & it’s automatically sandbox—which is great for one-offs or apps I don’t trust, like banks.
I suppose we have some engines like Qt, but from what I read QML doesn’t even perform as well as ‘the web’ while using web tech. Tauri & the like… also built on web tech. To build out the proprietary platforms, well now you need a huge matrix to test out new functionality & features—to the point that often other platforms don’t even get ported to despite it being ‘on the roadmap’ (looking at you iOS / macOS-only applications startups in particular).
If you have the resources (Claude has little excuse under this framing) or really need the performance or expect to be open 100% of the window session (coincidentally like a web browser), then yeah, going native is preferred—but for small shops, startups, one-offs (such as firmware updaters using the Bluetooth API that Mozilla sadly isn’t implementing) or short-session applications, web seems a smarter choice to be iterating on.
Windows and macOS are proprietary operating systems and so are their native APIs.
There are non-proprietary operating systems and APIs. It’s sad when native apps are no longer available for them.
On the other hand, it is really awesome that widespread support for web apps has made Linux so very competitive. I’m pretty down on what the Web has become, but I do love that I can live my life without needing Windows or macOS.
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. That explains the rise of Electron before LLM times, but it’s also a problem that LLMs solve now: if that was a real barrier to developing native apps, it doesn’t exist anymore.
This doesn't describe my experience at all. I enjoy making desktop software. The thing that kills or significantly hinders most of those projects is that most of the valuable content is published for the web. It is nearly impossible to embed a browser in a native app in a way that integrates with the native UI elements and make it cross-platform.
For example I recently wrote myself a rust-focused documentation browser. It kept breadcrumbs across crates in a particular way I find helpful, let me keep margin notes, etc. it works on Linux with GTK and the GTK port of Webkit. Unfortunately the GTK port of Webkit doesn't build on macOS. GTK doesn't expose the underlying AppKit primitive to use the conventional macOS WebKit build. I could use the wry crate that Tauri helpfully publishes but that hides most of the external control of the browser. i.e. A find-in-page feature must be built in the page with injected JavaScript because the navigation controller isn't wrapped.
In line with the post's topic, a shout out to Bogdan Popa who has written and published native(ish?) apps in Racket as well as Racket (for core logic) + Swift (for UI):
Just today I clicked on the (?) icon in the macOS slack app, because a dot there indicated a reply from support. It opened a completely blank window.
Native has nothing to offer, indeed.
The main problem is bad software, period. I think VS Code only exists to demonstrate that most Electron apps are crap. And I don't think the problem is bad developers: it's just that organizations know that making good apps does not make money. You might get good apps when someone wants to compete against an incumbent and similar situations. Otherwise, economy says do not optimize for performance if you don't absolutely need to.
Electron sucks too, but that's not really the problem.
I know a primary teacher that has switched to Linux. He plays constantly with GNOME apps and seems to be delighted with the experience (guy is also a Mac user).
I was doing some Gemini protocol work this weekend, so I was using Lagrange on desktop to test things. Lagrange is a graphical Gemini browser by a golden-age Nokia guy. It's a C/SDL application and it's absolutely delightful. It's not native by any means, but I wish Gemini had more success so I could read more stuff on Lagrange instead of dealing with the crappy web and annoying browsers- the guy makes an effort to make the application pleasant to use and it shows.
I just installed Tuba to do Fediverse stuff on my desktop. Let's see how that goes. (Although Enafore is another example that webapps can be great!)
OK, Tuba doesn't have good enough keyboard navigation. Anyone know a good ActivityPub/Fediverse/Mastodon desktop client that's good for keyboard use? Enafore is quite good.
So painful that there is still no shared browser binary all these apps could use.
Isn’t that basically how Tauri works?
Yes, it does work with the system WebView, but you rely on the OS for the updates and cross-platform compatibility becomes way harder, Electron is very successful at solving these issues.
That's how this works though: the OS provides the libraries which can be shared by all apps on the system, apps provide everything else. The shared browser all apps can use is the OS web view. What else do you want?
Since the codebase is usually shared with the web app and you can usually be more aggressive with it (if installed Safari stops working usually latest Chrome/FF are still available), it can be a bit tricky to ensure it works correctly on the oldest supported versions, or you need to deprecate aggressively.
cross-platform compatibility becomes way harder
Developers manage to write cross-browser websites every day.
So what I'm hearing is "WebkitGTK is way worse than any macOS or Windows developer could imagine".
IE is dead. Windows gives you just another flavor of Chromium.
Safari is strategically lagging behind in AppStore-revenue-hurting features, but everything you need to show a few buttons works fine.
Writing for an OS WebView on Windows and Apple platforms is easier than writing for the wild web. There are fewer variations to deal with, and you have way more control.
So what I'm hearing is "WebkitGTK is way worse than any macOS or Windows developer could imagine".
This was my takeaway when I looked into feedback from devs using Tauri. If you skip shipping Linux, it is not that bad, but old versions on macOS can still trip you; I think the main problem is that you need to approach testing in a very different way compared to Electron where normally just one version is enough to test.
The difference between a cross-platform Electron app and three native desktop apps is that the Electron app exists.
I didn't file this under ai or vibecoding because Claude in the title is only tangentially linked to the subject matter of the post.
On the other hand, I had to make do with programming and web because a gui tag is missing from lobste.rs. I wondered whether graphics was appropriate, but it felt low-level for this.
Kudos on finding something that genuinely didn't fit in the vibecoding tag and still mentioned Claude :)
What's next, a post about "Git" without the vcs tag?
the app you made today will look out of place next year, when Apple decides to change look and feel yet again
Except if you use native UI then when they change things your UI also changes and you don't have to do anything. When liquid glass came out my app's L&F updated automatically without me doing anything because I used SwiftUI
I didn’t get the point of this at all.
Looks could be good, but they also can be bad, and then you are stuck with platform-consistent, but generally bad UI (Liquid Glass ahem). It changes too often, too: the app you made today will look out of place next year, when Apple decides to change look and feel yet again. There’s no native look anymore.
Pick a lane! “Stuck with platform-consistent” is what “native UI” means. And the app you made today won’t look out of place next year, because Apple will change the look and feel for you.
Maybe the confusion here is that Windows is much, much worse at this — MS invented a long list of UI frameworks that look different and (weirdly for them) are completely backwards incompatible. I’d certainly buy that Microsoft doesn’t seriously want you to write native apps anymore.
To me native toolkits died with iOS 6, it just took a while for it to become clear.
This is partly because the Web has won anyway - many people spend more time on the "non-native" Web than in native toolkit apps, so they're used to Web's platform-agnostic mishmash of UIs (especially when many people split their time between desktop and mobile platforms that differ in their native UIs, but webby-apps can be equally non-native everywhere).
The native platforms, instead of doubling down on making their native UI visually distinctive and consistent beyond what the Web can do, have been sniffing "flat design" glue. Yeah, make your native buttons borderless rectangles. That will beat CSS!
When Apple and Microsoft chaotically half-redesign their OS look every year, users don't even know what native looks like anymore. Apps that follow the trends look more chaotic than if they do nothing and stay with their own Electron look.
Apple also shifted their design from simple and focused to dumbed-down and barren. They've been dismantling all the power-user level features. Their Catalyst and SwiftUI toolkits break all the little things just like Electron apps do. SwiftUI feels slower than React.
I could tell the take was bad just from the domain, not the first time I see opinions like that from the author
Everyone uses elector because it's cheaper, not because it's better. Sometimes cheaper is better, but not for people who value quality. For me, everything built* on elector sucks balls.
There are apps like Mullvad that have a good balance, however most of popular apps should invest in native, this is my take. I will not accept your lack of efforts for "innovation", sometimes you have to wake up your inner japanese and build a solid product
Minor feedback: At the very end that sentence should read "I just don’t think that kidding ourselves that [...] is productive." There's a "not" in there that shouldn't be right now.
I just don’t think that kidding ourselves that the only problem with software is Electron and it all will be butterflies and unicorns once we rewrite Slack in SwiftUI is not productive.
I would go further and say it may well be a downgrade. In my experience SwiftUI apps feel more sluggish than Electron apps.