6 ms·

> 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

> 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?

lazyjones 8y ago
> Do you actually have a million users? 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.
- MaulingMonkey 8y ago
  > Everybody who works on a cross-platform version of a generic utility has potentially many millions of users. 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? [1] https://en.wikipedia.org/wiki/Opportunity_cost https://en.wikipedia.org/wiki/Opportunity_cost
  - lazyjones 8y ago
    > I'm going to assume the answer is "no, this does not currently have a million users". 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.
    - MaulingMonkey 8y ago
      > You can spend all day asking irrelevant questions 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?
fxfan 8y ago
Slack probably does.

> 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?

lazyjones 8y ago

> Do you actually have a million users? 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.

MaulingMonkey 8y ago
> Everybody who works on a cross-platform version of a generic utility has potentially many millions of users. 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? [1] https://en.wikipedia.org/wiki/Opportunity_cost https://en.wikipedia.org/wiki/Opportunity_cost
- lazyjones 8y ago
  > I'm going to assume the answer is "no, this does not currently have a million users". 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.
  - MaulingMonkey 8y ago
    > You can spend all day asking irrelevant questions 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?

fxfan 8y ago

Slack probably does.