But it's convenient. I can't really fault people for using it.
I'm sure exact pinning is sometimes the real intended case for certain apps, as it is a value in certain ways, but I'd bet at least half the Electron apps I have running now would happily be using the same shared instance of the same LTS Chromium+Node if it were the out of the box behavior to be able to do so.
One thing that I really hope we see out of the LLM revolution: a return to native applications. You could argue that Electron cross-platform apps made sense when you had to pay a team to maintain two or three (at least) native clients; you can't make that argument anymore when the marginal cost of a line of code is $0.00.
I guess developers really prioritize velocity or ease over everything. Or maybe it's business pressure or directives?
Platform-specific views simply aren't. For simple applications they might make sense, but at a certain point devs just want the shit to work. Electron solved that.
I do agree that LLMs & co should contribute to reversing this trend, though. I don't really see why you couldn't try to ship (true) native now.
Maybe once we didn't dare surmount the challenge, but today, the landscape is a lot better (and a lot less chaotic) and while yeah it sort of sucks in some annoying ongoing ways I can't imagine every org is going to find this some insurmountable difficult strenuous activity. Like, get good.
The anti-will against doing this drives people away from the web as platform.
Most of the projects that I have seen are trying to push past that and get towards actual native-native (non-webview) rendering because despite being an even bigger pain and more work, they come out a lot better than the webviews.
2. While browsers are pretty compatible nowadays, not having to deal with WebKit/Safari quirks is a plus.
3. The platform webview isn’t necessarily that much more efficient.
Yes, they're getting their bonus. No, we can't hire and onboard more people to deal with the insane demands being made as a result. Why do you ask?
The sin is this ridiculous era of every program shipping its own runtime. I'm headed for real down votes, but this is the same lazy culture that's taken over everywhere: go and rust both ship these huge statically compiled binaries.
When you are a company, you're only running a handful of different workloads/apps on any given box, so the statically compiled price doesn't bite you. But as users, going back to dynamically linking and making the incremental cost of loading an app not also have to carry the entire world with it is such an obvious return, and one that alas seems to not be in progress at all.
The agentic age is, I hope, going to question a lot of old assumptions & needs about what we want to run. Having lots of small resident little user agencies, compiled small scripts that are attributed to a user, is something I believe will happen, but I'm less convinced we'll recognize the face of it as it happens, that the tales will be told.
Tools like agent-substrate, ax, scion, are this interesting mix between agents, serverless, and kubernetes. I find it fascinating. (For hire on this.) https://github.com/agent-substrate/substrate
> The sin is this ridiculous era of every program shipping its own runtime. I'm headed for real down votes, but this is the same lazy culture that's taken over everywhere: go and rust both ship these huge statically compiled binaries.
Go and Rust are pretty efficient too, if your architecture isn't trash. If it is, they still probably are more efficient than Electron
Rust and go are somewhere on the continuum, between dynlibs and chrome, for how much private world they build for themselves. It's vastly less than chrome. But it's a lot. A lot more than what Linux distributions did for years and years and years.
Especially if you think if multiuser systems with multiple people using programs, then you have some scaling factor. Then it matters a lot a lot more than each lib has to be loaded distinctly for each process.
It's not good. It's not good for Electron, there are vastly better ways to run many apps taking a more dynlib path, and it's not good for rust or go. As nice as it is to dev like that.
Of course it's another huge problem that dependency trees are rarely shared. Go look at Class Data Sharing in Java: building the libs you standardize on (your orgs stdlibs) and there's this beautiful idea here that you should just already have some common things expected to be there. That's harder to imagine since so many programs have such different dep stacks. But imagine having a Tokio or tokio+++ that everyone can use, good foundational tools (Grand Central dispatch and the never arrived NextBSD) Some common substrate, with just like async as one example. And the size of that shared good useful library/platform can grow, hopefully revive an interest in reuse vs bringing your own every time. https://docs.oracle.com/en/java/javase/17/vm/class-data-shar...