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.
Uphill both ways, should be easy for a company doing C compilers with LLMs.
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.
There's also stuff like lorca which shells out to an installed Chromium browser.
But I think even there it’s possible to encounter platform-dependent bugs - starting from view issues (you know, different OS can use different browser engines) and up to those related to system APIs.
Go figure what would happen when Chrome gets shipped everywhere, because writing browser agnostic code is too hard.
I understand why, but there is such beauty in the simplicity of ansi.
I’ve built for Electron and did a course on Swift for macOS apps. Not out of laziness, but I don’t think I’d ever build native for Macs. And the Windows folk have been complaining for a long time about the native APIs.
Now, native on mobile, that’s something else. I’ve been stuck on RN/Expo because that’s what the resources the business had allowed for, but native Kotlin is much more enjoyable (AFAIK). Swift… dunno, still icky.
"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)."
Since the discussion was specifically about platform-consistency, odd that the author would decide that personal taste might take priority over platform-consistency.
"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."
Seems to be arguing the exact opposite? If you adopt a native API for controls, windows, etc., your app will change next year to look completely in place (perhaps for better or worse according to the author).
Going DIY on UI and your app might still, in 2026, have brushed aluminum and "lickable" buttons.
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 do realise the need for abstractions and they do exist, provided there is actually the interest to learn them.
https://www.embarcadero.com/products/delphi
One of the related conferences just took place last October,
I've been in a few companies that managed to eke out a living by maintaining a piece of software no one in their sane mind would still maintain. Sometimes a government gig, sometimes the private sector.
Shoutout to my boys that in 2018 maintained a Java 1.3 app. Still going strong to this day (it was migrated to Java 8 last time I checked).
EDIT: ~21 Delphi apps in world! Woohoo! Delphi number #525
> Most of those Electron folks would not manage to even write C applications on an Amiga, use Delphi, VB, or whatever.
It's not just the difficulty. It's the lack of learning materials, widgets, examples, and whatnot. Debuggers also suck, at least they did when I used Delphi.
What also helps is having a huge behemoth of a corporation improving your GUI toolkit for free (Chromium, although you pay in ad exposure).
The sad reality is everyone wanting to have fancy looking pages/apps as quickly and easily as possible.
And now, the web (and increasingly desktop) is littered with the lowest common denominator of platforms with all sorts of crazy optimizations that still can’t be as snappy as a Windows 95 app on a 200mhz / 16MB desktop.
At this point we may as well just use electron and nodejs for fighter jets and missile defense systems. Surely it’s fast enough for that, too.
Electron is bad, but it's the least bad of all other cross-platform GUIs.
> Most of those Electron folks would not manage to even write C applications on an Amiga, use Delphi, VB, or whatever.
That's true of most people on the planet. No one has access to them.
Don't use Discord, never plan to. Even if I cared, I would only use the browser as it should be.
Slack only lives on the browser, as it should.
VSCode is only used when there are no SDKs for my editors or IDEs, and I am forced into VSCode.
However contrary to Electron crap, VSCode at least has tons of external processes written in a mix of C++, Rust and C#, and parts of it have moved into WebGL, not the traditional Electron crap application.
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.
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.
React is no innovation at all, some folks got a bit enthusiastic with Haskell reactive programming papers.
No way someone really used Delphi and claims that it is faster to build UI with HTML/CSS/JS stack.
Best time I ever had in a job was writing WPF applications in C# using ReactiveUI. Once we really understood the underlying model we were plugging stuff together so easily. It is a really good model, but I can't see how React is a good example of it.
Of course I had lots to complain about then, WPF had bugs, C# has a number of big problems, but it was, overall, very nice.
You just need to point it in the right direction (c/rust/go etc) and be harsh with the requirements, especially memory usage.
If I was Microsoft I would use AI for this rather than badly embedding AI everywhere, a lot of power users would be overwhelmed by a win 11 update where OS apps/features dropped mem usage by 90%+
Oh wait no that would be incredibly painful for everyone. Yes reducing memory requirements would be great but not at that cost.
> The real problem is a lack of care. And the slop; you can build it with any stack.
so you agree.
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.
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.
And if MS stopped randomly moving things around in the UI with no benefit whatsoever, their documentation could be usefull instead of telling me where I could find some setting 3 years ago.
Someone needed actual malice to write that monster.
Ironic statement, given that Claude Code is exactly that.
So maybe Claude could have used another cross-platform desktop development framework, but Electron was better/faster.