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.)
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.
I understand why, but there is such beauty in the simplicity of ansi.
Uphill both ways, should be easy for a company doing C compilers with LLMs.
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)
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.
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).
It may depend on which SDK version the developer uses.
Sure I never understood AutoLayout, but how many people really do? Every new screen size broke tons of apps. My high school ObjC app developed for the iPhone 1 using C macros to calculate dimensions still worked fine on later models. And yes CSS is fragile too.
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.
- 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.
I had to add strict ESLint and TypeScript rules to keep guardrails on the coding agents.
Ultimately, Claude having limitations is an issue. They can't just point it at the code base and ask it to make it faster.
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.
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.
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...
My eyes! The goggles, they do nothing!
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.
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 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.
ttd•1h ago
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.
usrnm•44m ago
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?
zadikian•29m ago
IncreasePosts•23m ago
mandevil•17m ago
zadikian•14m ago
jerf•15m ago
"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."
recursive•14m ago
mjr00•6m ago
davorak•4m ago
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.