Literally anything is a good alternative to electron. One should prioritize the quality of the product, and use of electron gives the lowest quality product.
Flutter / Dart? It's compiled ahead of time and doesn't use an embedded browser so I'd expect it to be a lot lighter, though I haven't measured.
But the general lack of really cross-platform (desktop + mobile + maybe web) ecosystems is just as much as sign that devs consider multi-gigabyte Electron apps "good enough" as the apps themselves.
>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.
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).
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.
What I'm seeing more and more of is junior folks blindly taking LLM-generated code and including it into their systems, without even trying to understand it or think critically about what it does and where it might break.
Maybe I am living in the past, but it does make me think that they might be depriving themselves of an opportunity to develop key skills.
>without even trying to understand it or think critically about what it does and where it might break.
You are living in a past, but one much farther back than you expect.
People were copying code from SO since it became popular.
People are including node modules blindly before AI.
Most developers suck, terribly. Maybe being on HN is a type of filter that shows you're just a little bit better than the average, but the number of developers on HN is small versus the total number of developers.
Edit: I was copying code out of magazines to get games running without understanding anything about it when I was young.
First of all, that's a very different sort of thing compared to blindly taking reams of code from an LLM. The amounts of code in a given SO answer or a magazine article are tiny and the code has undergone review of one sort or another. Similarly, if I take QR decomposition code from Numerical Recipes, that's quite likely to be better quality than what I -- or most folks -- can code up in a comparable amount of time. It's also an opportunity to learn by studying the code and the method.
Secondly, I am not talking about some abstract SWEs in a vacuum. This is happening to real people I work with, whom I know to be very capable. The lure of switching off the brain and just clicking "Accept" to some LLM suggestion seems too strong to resist. :(
Really what you're saying is it is an issue of quantity.
> if I take QR decomposition code from Numerical Recipes,
I'm going to assume the vast majority of code written does not look anything like this, but is dumb little chunks of glue for other important chunks, that are quite often imported from other libraries.
As someone that is not a SWE looking from the outside, I think there is a disconnect between what a SWE is told they are getting paid for and what a SWE is actually getting paid for by (many/most) businesses.
You are under the assumption you are getting paid for writing code. But for the vast majority of business that is just the icky bits getting ground up in the sausage factory that nobody wants to know about. Management above you only cares about what gets wrapped in casings and is ready to sell to the customer (either internal or external). They do not care if the product is technically good as long as they can sell it. For each individual person in the company becoming a better programmer is hard to measure and rarely rewarded by the company they work for. Turning out tons of lines of code and applications that have at least some semblance of working is far more likely to get you a pay raise.
I think we're talking past each other a little bit.
You're talking in the aggregate and making some good points.
I am talking about what concretely I am seeing on the ground. It's become a little too easy to churn out junk that looks plausible enough to pass the initial sniff test but that ultimately results in negative productivity. Someone has to go back and not only redo the initial work but also deal with all the knock-on effects. It's unclear to me that these effects are offset by productivity gains elsewhere. This can also result in highly problematic incentive structures: the initial launch ticks some box, whoever did it gets rewarded and then someone else is left to pick up the pieces. Higher overall cost to the orgnisation and worse experience for the customers than doing it well in the first place.
Not totally clear how to fix this other than by shifting towards longer-term incentive structures (which have their own drawbacks).
None of this is completely new, but has become 10X easier thanks to the current generation of tooling.
This is in addition to my concerns around what this is doing to our junior developers' skills.
Maybe the tooling will soon get good enough that nobody has to ever write any code except for enjoyment, but it's not clear to me that this is the trajectory we're on.
People wouldnt use electron is they had good alternative