> I don't understand why using electron is considered "inconsiderate".

Because I chose my OS carefully and found that I like the way its native controls work. It has a number of features missing from other OSes and I want to use apps that integrate naturally with it. I have yet to find an electron app (or web app) that is 1/10th as good as a native app at fulfilling that desire. Electron apps feel like generic imitations of native apps. Yeah, they work, but everything is just off. Also, it comes from Google so I can only assume it's doing some sort of tracking of me and/or my machine resources. No thank you.

> Is it inconsiderate for Ford to make a larger SUV

It depends on which dimension they extend it and by how much. If they make it wider to where it doesn't fit in a lane on a normal road, then hell yes it's inconsiderate. That's essentially what electron does.

I'm an developer who's been using electron since it came out. At it's core electron is just a packaged NodeJS instance with a layer to access the OS API. The chrome as a GUI part does not have to be used. This makes electron a great way to distribute NodeJS apps. Instead of getting your users to install NodeJS and use the command line, you can give them an electron version of the app that works out of the box.

If you stick to using the GUI part minimally, it's easy to build very light weight applications with electron. I've been building my own music streaming server with electron and its gotten some traction since it's easier to install. The GUI layer is only used for editing config options, so the app typically runs with under 50mb of memory consumption: https://github.com/IrosTheBeggar/mStream/releases

If used smartly, electron is a powerful tool for developing desktop apps quickly. However thanks to modern frontend dev practices, it's easy to build a bloated pile of crap.

In the US, a Ford XL SUV will get killed by the DOT if it does fit in standard lane sizes, among other considerations. I am sure this is why there comparatively few brands of automobiles here

There is no such governing body for Electron, save for the nebulous "market"; nobody with any authority is forcing them (GitHub et al) to fix their shit or GTFO

> Also, it comes from Google so I can only assume it's doing some sort of tracking of me and/or my machine resources. No thank you.

Electron was developed by GitHub for their Atom editor, actually.

The way I see it, user's resources (and their experience related to these factors) aren't part of the calculus that goes into how most companies choose their platforms. To be fair, things have always been this way -- people have been writing good-but-bloated software in shitty frameworks since forever -- but I can't recall a time that one framework so bloated is so heavily in vogue.

(edit: Flash, maybe? Though people mostly didn't try to write too many full apps in it. And Flash projects could be fairly CPU-efficient if effort was put into it, but way less effort than, say, MS with VS Code)

I'm fortunate enough to work for a company that sees being thrifty with bandwidth and processing as very important.

We have regular audits to find ways to make things lighter/faster, and therefore better. Occasionally "flashier" mandates from on high override those considerations, but so far it's been specific and rare.

It's probably because our target audience isn't developers.

Funny, following that logic one would think that developers would be the most picky about performance...

Old developers. Seasoned developers. Developers who know what they're doing.

But the devs coming out of schools today (and half of HN) believe it's OK to build a skyscraper by stacking frameworks one upon the other.

I agree with you that efficient resource usage is pretty low on the priority list for a lot of development these days. I wish it wasn't too but that's a different discussion.

Electron being in vogue does definitely compound this issue but the benefits from using it (e.g. cross OS development on a familiar platform & language many devs already know) seem to outweigh the resource problem.

That's because the devs are not the ones to face the resource problem.

There are many devs that know regular desktop development as well; Electron lets the project manager hire cheaper and more expendable web devs, or the ability to pile the job on their existing web devs, for their otherwise expensive desktop work.

Do any major code bootcamps teach C#, C++, or Java? Or is it all just webtech?

I wrote a tiny app in flash / AS3 back in the day, a CAD floorplan viewer in a few hundred KB, including baked-in artwork and font. CPU and memory use was quite low. I never considered flash to be bloated or slow. The way most people used it made it bloated and slow, with heavy software-based vector animation, tons of video, and flex. Flex was very developer-friendly but also quite bloated, so I never used it.

I wonder if electron is a bit of the same deal, with the recommended way of using it optimizing for developer efficiency over resource efficiency.

I don't feel the developer used what they felt was best for this app. I feel they used what was best for them.

Assuming the best platform for an app was even something that you could objectively determine, why would you expect a solo developer to write an app in a platform that isn't the best for them?

To write something that's best for the customer, of course. The goal of development shouldn't be to build something that's easy for the developer but suboptimal for the customer.

This isn't open source, and the implication is that they plan on selling it. If so, then what's best for the customer should be paramount.