Wow, this is waaaay too big for my taste.
I'm absolutely sure it is possible to write the same cross-platform app for less than 500KBytes and no dependencies.
I'm absolutely sure it is possible to write the same cross-platform app for less than 500KBytes and no dependencies.
This is an answer without a real problem, for Mac users anyway.
Everyone here loves to virtue signal about how horrible programs that take 0.01% of the space of a normal SSD and 1% of the RAM are, but the fact is that it does not matter at all, and you wouldn't even have noticed if you hadn't intentionally looked at the size of it.
How about developer time of 1 person vs. hardware (and electricity, CO2 emissions...) of 1 million users?
Do you actually have a million users? Can that developer time be spent saving even more hardware or human costs elsewhere?
Everybody who works on a cross-platform version of a generic utility has potentially many millions of users.
> Can that developer time be spent saving even more hardware or human costs elsewhere?
Nobody knows. But it's obvious that wasting resources like this is going to scale with every user - even non-users who just download out of curiosity.
Not the same thing. And other threads have established there are already popular color pickers this would be competing with if rewritten in a native lean style, that this would first need to take mindshare away from as well.
I'm going to assume the answer is "no, this does not currently have a million users".
> Nobody knows.
We can make reasonable guesses. For one, I bet the author can get hired to work on a codebase that actually has a million users, not any of this "potentially maybe in the future" stuff. For another, I know for a fact that many of those codebases - even the native ones - have bigger perf problems, and a lot more room to optimize towards the ideal.
I'm going to assume the answer is "yes, that developer time can be more efficiently used."
> But it's obvious that wasting resources like this is going to scale with every user.
This we can agree on. But there's an opportunity cost[1] to fixing that. Going to the root of the hosting site, it clearly states the author is a webdev, so "fixing" that in the "let's not use electron" sense might involve learning Rust or some other native language first. That's not insignificant. And then you're competing with other already existing perfectly functional native color pickers... so are you actually saving significant hardware costs?
You can spend all day asking irrelevant questions and answering them yourself, it won't get us anywhere.
The point is that "developer time is more expensive than hardware" is not a valid argument from the user's perspective. As you can see from the complaints here, people already find the color picker less attractive because it uses wasteful Electron. It's not a good product, regardless of how cheap it was for the developer to produce and will be less successful as a result.
You don't need justification for developing something that isn't good because of wrong or selfish priorities, but you'd better accept that success of your product and its environmental footprint depends on these priorities too.
We're discussing how dev time is best spent in service to the end user (and environment.) It's absolutely relevant.
> The point is that "developer time is more expensive than hardware" is not a valid argument from the user's perspective. As you can see from the complaints here, people already find the color picker less attractive because it uses wasteful Electron. It's not a good product, regardless of how cheap it was for the developer to produce and will be less successful as a result.
Things the end user does care about include features, price, and the actual existence of the end product, all things I see frequently sacrificed by the "maximum efficiency at any cost" crowd, because they're misallocating dev time. They aren't even optimizing the actual efficiency bottlenecks half the time, just micro-optimizing some unimportant edge case.
You're right that the discussion doesn't matter to the end user, but that doesn't mean it's the wrong decision. As you can also see from the posts here, not everyone is convinced it's a big deal either. People are constructing strawman arguments "these devs and their 4k monitors and 32GB+ machines", but I'm using electron apps from an underpowered 8GB laptop just fine.
Yes, if you're traveling and downloading it over a mobile connection, it'll take a hit. Yes, I'm sure you can find a worse laptop than mine, and if you search hard enough you'll even find one where the fact that it's an electron app will be a problem. Yes, you can spend more resources to make a better app - that's always true, the question is where diminishing returns make that no longer cost effective. Yes, if there's no outlets nearby, it won't stretch battery life as far.
But no, I'm not convinced that calling it "not a good product" as a result of being an electron app is quite right either. Not the best product it possibly could be, but no product is.
> You don't need justification for developing something that isn't good because of wrong or selfish priorities,
Nor am I convinced there are wrong or selfish priorities in using electron. What, exactly, is wrong or selfish with saving dev time to work on something more important to the end user? Even if that's another product entirely?
It's simply completely irrelevant what the developer might or might not be working on also in your imagination, when we are judging the product based on its technical merits.
Inventing some extremely important better use of the developer's time to justify inflicting a wasteful 55MB download on the world, is a strawman argument of the same quality you complained about.
And if we're limiting the discussion to just the technical merits of a product, I'm not sure why you started discussing developer time and expense at all. You're the one who brought up "dev time vs millions of users hardware", and I'm just pointing out that it's perhaps more realistic to view this as "dev time" vs "thousands of users hardware" in this particular case, and that there's a lot of mildly important things the developer could work on instead.
For that matter, I did notice the size, as I'm browsing on a mobile connection (travelling) and the 55M color picker utility would take a bit over 2 minutes to download.
Phones for example have basically been unchanged for 5 years regarding performance, because while hardware has drastically improved the apps have become heavier in proportion for superficial new features. Same goes for internet connections.
As another example I'd say that the recent resurgence of deep learning has mostly come from (or at least was catalysed by) cheap, affordable GPUs, which only exist because gamers wanted better and better graphics.
We're already at the point where hardware is marginally increasing in efficiency year-over-year for most purposes. We've been there for like, 4-5 years now. Chips created on high-end processes are already expensive to the point there's no immediate cost-savings to be had from them, only power savings. Twice as dense, twice as expensive, marginal performance improvements. Years of development.
That's due to physical laws of nature, not because we suddenly started writing way, way better software and therefore hardware engineers decided to slack off for the past 8-5 years or whatever, after year-over-year doubling in the prior decades. Your lunch was never actually free, it's just that Bill down the hall has finally stopped paying for you every day, because he's starting to go broke and has to tighten his belt.
> that it is good that software is becoming more and more "bloated"
No it isn't, you only think that (and justify it with a speculative argument) because it lets you justify externalizing the costs of bloat onto someone else, ignoring any other concerns -- your users, your cloud provider, your hardware vendors, etc who all pay for the energy and time you wasted on their behalf.
> that's the only incentive to keep researching more efficient hardware.
No it isn't, this is just more baseless speculation to support your point.
I don't see it. The latest version of iOS is (apparently) such a big performance improvement that its performance got top billing as a "Feature" from Apple [1]. They brag about how it's ~50% faster at several common tasks.
Short thread on the matter: https://twitter.com/Wunkolo/status/1091572380315439104