Electron's more-or-less just Chrome without... erm... chrome, so it makes sense that it's bloated and uses too much RAM. Even well-constructed and efficient JavaScript executed through it will do so on top of a bunch of stuff your application might not even need.

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.

▲

floydnoel 2 hours ago | parent | next [-]

What I don’t understand is, why not just use a platform native webview? Mac has it at least, I think Windows does as well. You'd think it would be the same amount of work (roughly) but use a lot less memory.

I guess developers really prioritize velocity or ease over everything. Or maybe it's business pressure or directives?

	▲	Klonoar 2 hours ago \| parent \| next [-]
		There's a comment somewhere on HN from a Slack dev who was the one responsible for moving away from platform-specific webviews to Electron. The core reason is that Electron is the same on all platforms it ships on, generally speaking. 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.
	▲	skrtskrt 8 minutes ago \| parent \| prev \| next [-]
		I mean if you look at all the frameworks that are trying to push towards native support across platorms, the ones that are took a pit stop at platform-native webviews, before going full native all have negative opinions of platform-native webviews. Besides all the tons of effort and buggy sharp corners there are across platforms, a lot of them just make really crappy UIs. 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.
	▲	freedomben 2 hours ago \| parent \| prev \| next [-]
		There's Tauri, but (at least when I tried it last) it had bugs that made building functioning RPM packages extremely difficult. Bug(s) had been there for over a year at least with no momentum, so if you need to support rpm-based distros you're in for a rough time.
	▲	lenerdenator 2 hours ago \| parent \| prev [-]
		Business pressure. Always business pressure. Sales sold a bill of goods and now you need to deliver ASAP. Hardware was cheaper than dev time. Was. 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?

▲

jauntywundrkind an hour ago | parent | prev [-]

Chrome is pretty efficient, as far as per page costs go! If your architecture isn't trash!

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

	▲	saghm 37 minutes ago \| parent [-]
		> Chrome is pretty efficient, as far as per page costs go! If your architecture isn't trash! > 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