>at devs consider multi-gigabyte Electron apps "good enough" as the apps themselves.

This kind of misses out on a hierarchy of devs here and the amount of work to make it happen. Electron took a large chunk from a multi-billion dollar endeavor to use to make all this work. Electron only worked because Chrome was there. Chrome worked because Google already had unlimited money from advertising, and getting advertising on every device possible was their goal.

Devs might want light apps everywhere, but seemingly none are going to dedicate the rest of their life and money to make it work.

▲

quietbritishjim an hour ago | parent [-]

True, not every dev has the power of a multi-billion dollar company behind them. But a few do.

My point was, if enough people really considered this a big deal then at least one huge tech company might have invested in a solution that provides a lighter weight solution that's truely multiplatform (desktop and mobile).

I don't have much visibility on how decisions are made to maintain massive open-source infrastructure projects, and no doubt there are significant business case inputs to them, but they must be at least partially technical. So, as I see it, the lack of such things give insight that even developers don't prioritise them.

As I mentioned, Flutter is almost there and maybe its lack of uptake on desktop is just enough to show that there really isn't demand (though I expect the main reason is its use of the Dart programming language, which is very nice but quite niche).

	▲	pixl97 26 minutes ago \| parent [-]
		>but they must be at least partially technical. Having sat in many a meeting, partially yes, but these things are massively expensive. There is an equation, How much would it cost us to write a replacement that covers what we need versus how much does it cost us to use what exists that isn't efficient. And this is where you miss the biggest part of the problem. It's the end users that bear the biggest part of the costs. Yes, there is an internal cost for their own developers, but that is comparatively small to the costs of their paychecks. The next comes to management of the lightweight solution over time. If it's owned by a company at the end of the day companies are rarely interested in lightweight, they are interested in making the most money and quite often that means adding more and more features to accomplish lock-in. Open source is more likely to keep a project remaining light, but to do that it's quite often by not accepting bulky features that would make companies more money. So you see where the catch-22 situation starts to arise from.