I can't upvote this enough. It is such a simple, yet effective way of demonstrating where inefficiencies of code have a real-world impact. I'm going to use this in future discussions. People often see such metrics in isolation, without understanding the larger impact of why it's important to write more efficient code.
I work with server-side code mostly, and the same principle applies. If I can save the server even 1 second of processing on a given request, then it means that every instance of this request has time saved. Which means that many concurrent requests will not use as much of the server's resources.
^ applies to client side code as well, which means if you replace "server" with "client" (desktop / mobile), then you still have the same gains.
I always thought the whole "humans won't notice the performance improvements" thing bogus. Sure, they probably won't see a difference.
However their machines do. Sure, we are building applications for humans, but that doesn't mean we should overlook performance that only machines will notice.
There is a downside. Typically most performance tuned code has greatly reduced human readability, like the solution provided in this article.
Sometimes, it's a price we have to pay if completely necessary. Indeed, it is frustrating how we can't have both readability and performance. Perhaps transpilers can be used to somehow convert less performant code to their more performant counterparts, but then that's just adding a whole new layer of complexity to the project. It isn't really a "solution" per se.
Transpilation seems like the cheapest of the three possible options to me.
Though, I don't see a lot of transpilation optimizing for performance.
I feel like we have the community for such an undertaking now, but those that care about raw performance of their web scripts have now focused on WASM instead. Which is a smart move, and has a lot more potential.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.