And, heck, there's a solid argument that server-side rendering is more environmentally efficient, since the work is done in a data-center, which can (1) utilize caching to avoid re-doing work and (2) be built in an optimal location for electricity generation.

Conversely, you are losing the distributed computing gained by rendering on the client, and therefore need a bigger server to scale when needed. And HTTP caching can and should be used for API responses as well.

If we're measuring by total resource consumption regardless of location, is distributed computing beneficial? Your server can be less powerful, but the client needs to be more powerful. I'd think the primary difference is who's paying for it.

Sure, most clients may already be adequately provisioned, but only because so many websites with bloated Javascript have forced their hand...

>Maybe they are, but that bloat is just some static files that are sent to the user as far as the web server is concerned. They should have no practical impact on the battery life of the server."

...and if those static files make 100 API calls as soon as they land?

I think he is talking about badly written JS code serving the APIs and the overhead of it.

Of course it's hard to debate whether JS, Java or PHP is most inefficient in that regard.

I strongly believe that the efficiency of an API is 1% down to the language it's coded in, and 99% down to who coded it.

Yes and no; while it's still true that you can write FORTRAN in any language, there are network effects that mean the effort required to write efficient code is different per language/community/framework.

I think that’s true if you take a no dependencies approach but as soon as you tap into the ecosystem the argument is lost.

Not really. It still depends on who coded it. It's just that there's more people involved now.

Corollary: The average API is far less efficient than the languages you like to complain about their efficiency.