@ZeroEcks Oh yeah, there are certainly valid criticisms to be directed at Electron. But crucially those are never the ones that people actually bring up, and the people complaining about Electron are *also* never the ones willing to contribute to getting the remaining issues fixed.

@joepie91 well I would have to actually contribute and maintain things so I'd rather not, if every complainer actually contributed a fix we could get places.

I think my main complaint is actually that it should be easier for me to update companies electron for them though, like how Wayland support is much improved but a bunch of apps don't ship with it. But arch solves that with their "system electron" packages so idm. Probably says a lot about how much it's improving too.

@ZeroEcks Honestly you can just use the system Electron for like 95% of Electron apps in my experience without anything meaningfully breaking, I've been doing that for years, the whole "shipping an Electron with every application" was more of an invention by tech companies because they didn't want to deal with package managers, originally it was meant to be used with a system runtime much like Node

@ZeroEcks @joepie91 ime all the electron apps I've used work better with better sandboxing and less total RAM use by running the web app in my normal browser

(My foreground tasks are often io limited where as much disk cache as possible saves me time, and I don't know how electron handles that memory pressure)

@artemist @ZeroEcks Note that Electron also does sandboxing by default and it's generally a choice of the publisher of the software to explicitly turn that off (for a variety of reasons, most of them bad)

@freakazoid It's not. The goal of Electron, especially of the broader community originally around it, was to make the frankly just better application design tooling of browsers (CSS in particular) available for desktop development, because historically UI toolkits, especially the cross-platform ones, have sucked shit (and in many ways still do).

It's just that capitalists saw this as a way to cut costs.

@freakazoid (Do note that at the time of introduction of Electron, CSS and versions thereof were not actually a thing in other UI toolkits - that only came much later, and even then usually in a much more restricted and janky form)

@joepie91 But isn't resource usage (not to mention download size) going to be high in Electron pretty much no matter what you do? Browsers aren't exactly small. Microsoft managed to avoid that while still supporting HTML and CSS by sharing everything AIUI. Which is a security nightmare the way they did it.

I absolutely support the end goal. It's just that using a full-blown browser for each application seems like the epitome of focusing on developer convenience over user needs, which is IMO a big reason why free software has struggled to compete with the capitalist model.

@joepie91 I feel like this Microsoft-technology-from-20-years-ago would make a great basis for a next-generation desktop environment. One rendering engine, one JS engine, all your applications/components.

Yes, that's essentially ChromeOS I guess. Maybe we should just fork it? I think to make a new DE work we'd need to take things away from Linux, not add more. No OS package manager (just Flatpak), etc.

@freakazoid "But isn't resource usage (not to mention download size) going to be high in Electron pretty much no matter what you do?"

Short answer: no, it's not. Electron does not have 'high resource usage' and never did.

"It's just that using a full-blown browser for each application"

Electron isn't a "full-blown browser" and this is very much part of the misinformation that is causing all this bullshit. Its internal complexity is not meaningfully higher than that of a modern UI toolkit, and it's not Chromium either.

@freakazoid Like, all of these claims are literally just false, but nobody ever bothers to actually *check* them before repeating them.

@joepie91 I'd certainly fallen for them, having heard them many times and never having heard anyone contradict it!

Time for me to go learn about Electron!

@freakazoid Some pointers to that end: the actual thing that Electron uses is CEF, Chromium Embedded Framework, which can more or less be thought of as "just the engine part of Chromium without all the other browser stuff" (ie. mostly just layout, parsing, and an embedded JS runtime, similar to modern UI toolkits), the baseline memory use of Electron is somewhere in the region of 50MB at most, V8 is a very fast and well-optimized JS runtime (achieving close to C performance in some cases... and often better performance in typical I/O-bound scenarios), and most of the 'memory use' of both V8 and the rendering subsystem are optimistic memory allocations/retaining that are not actually used yet to prevent memory fragmentation, and which disappears under memory pressure.