I was expecting something like using serverless, or serving only static content or something.
There's just no way that "write less JavaScript" is the big needle mover compared to right sizing and scaling your fleet. Right?
Also, rather than spending two days optimizing all this, wouldn't you see much more carbon removed by spending two days planting trees?
Is that a reason not to try to make things more efficient?
> There's just no way that "write less JavaScript" is the big needle mover compared to right sizing and scaling your fleet. Right?
My understanding is that it's less "write less JavaScript" and more "Don't pull in MB after MB of dependencies".
Also, that was just one of several points made by the author.
> Also, rather than spending two days optimizing all this, wouldn't you see much more carbon removed by spending two days planting trees?
Por que no los dos? As a result of the author having done so, it has now saved others who are interested in doing so time learning how.
Probably good practice regardless. Recently saw a project with 23,000 lines of CSS thanks to pulling in library after library. That's just hard to reason about come maintenance time.
Increasing efficiency has both a cost (how many hours did it take to improve this, and how much power was spent on competing to develop them) and and opportunity cost (what could we have spent those hours on instead). If the efficiency gain never repays the cost, you've actually made the system worse by making it more efficient.
There are no claims from the author about what is saved, it seems like the amount of energy spent reclaiming a small amount of energy will lately be worthwhile.
Let's assume a smartphone has a battery capacity of 10WH (3000mAH * 3.7v), and you're charging your phone once per day to make up for aggregate inefficiency. If retail electric is priced at $0.10 per KWH, that's 36 cents per year? On the emissions front, that's negligible.
However, at least hitting the low hanging fruit seems like a good idea.
It's like spending an extra ten dollars once to save a tenth of a penny on each future tank of gas. Yes, there are times where that trade-off makes sense, but for most folks it won't actually make things better and could make them worse.
The author doesn't have any data to suggest what the savings here are. I assume these are miniscule or even immeasurable benefits that come at a very real cost in time and resources.
The world probably doesn't need my VM running 24/7 on the other hand. My server is in Singapore and in theory that means it's running on natural gas with Singapore getting 95% of it's power from natural gas. Better than coal, but still not great.
It's fun to think about how all this software manifests in real world, it's easy to pay it no attention.