How did the idea of avoiding premature optimization get misapplied to client-side apps where the entity writing the software is not the one paying for electricity, cooling, and people's time when the software takes much longer to run than it could? When did a lot of software devs stop caring?
Pardon me, I think there are some electron devs at my door asking for a word. They might have baseball bats.
Premature optimization should be avoided client side as well I imagine? It just seems like lots of development shops skip optimization altogether, even when it stops being Premature (when it matures?).
And it's not like those Shops suffer for it, so it isn't very surprising they continue.
I'm not sure the devs stopped caring as much as the powers at be. Software development has become more commoditized than we want to believe. Devs following an agile workflow with every intent of performing multiple rounds of optimization find that the product gets shipped as soon as it approximates the thing that had been conceived originally.
It doesn't look like an immediate failure, so the less that leadership takes from it is frequently that the level of maturity they shipped is safe. The cycle continues and eventually folks lower down succumb to this shipping pattern. The only things that get them to optimize is competition that successfully drive home their win was due to performance. This doesn't always lead to optimizations when you are an incumbent who can still close more feature gaps because those often result in higher sales and revenue.
I use a 7 year old low-power laptop. Cooling, electricity usage, and performance of Electron apps are never an issue. Crashes, bugs, lost data, and bad usability still are. I’d rather have devs spend time on that stuff.
If Electron frees up organizational resources to do what’s actually important, I applaud devs for using it.
Not an issue for you, that you know of, because you have no equivalent software that's written in a more performant language (or at least critical portions of the codebase written in a more performant language). That's part of the problem; in most cases, software users don't know what life would be like with better software. They assume the performance they see is close to optimal, or at least that the devs made an effort to optimize. Users are willing to get used to whatever the software's performance is, in order to have access to the software's features. You can get used to almost anything, as suboptimal performance turns into background noise, but that doesn't mean you should. You get used to waiting 5 seconds for a piece of software to do something that you do on average once every hour or two, not realizing that those 5 seconds, 10 times a day, 365 days a year, cost you 5 hours every year.
Optimizing performance and fixing crashes/bugs/dataloss aren't mutually exclusive, either. Developers who care less about code quality than checking boxes for features requested by management or customers, will write code that's both suboptimal and buggy.
Pardon me, I think there are some electron devs at my door asking for a word. They might have baseball bats.