One advantage of pushing the computing on the user-side is that it reduces the load on the server: less requests, less processing and smaller request sizes. Thus it reduces the bill for the developers/companies :)

The server load from a server-side rendered page vs an API call that returns JSON is... very minimal.

Unless you're building at great scale, it's such a negligible difference that it really shouldn't be part of your decision making process, IMHO.

[Edit: I don't want to get into this argument right now]

the original web architecture has sophisticated client-side caching built into it, all modern browsers support it:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching

the difference between constructing a string of JSON and a string of HTML is a round off error when compared with network connection costs and data store accesses, etc.

I'm guessing you haven't measured it, as IME it certainly is true. Try it, you might be surprised.

Also, SSR'd pages can be cached too.

"The server load from a server-side rendered page vs an API call that returns JSON is... very minimal."

That greatly depends how you designed your architecture and if you have just a simple webpage or a sophisticated webapp displaying data in various ways.

My main app is designed to work mainly offline, with bursts of data transfer. All the state is local. Sending html from the server would mean in my case, the server would need to know and keep track of all the user states and data.

>One advantage of pushing the computing on the user-side is that it reduces the load on the server:

But we don't need complicated frameworks on the server, keeping track of changes in a shadow DOM and updating the real DOM afterwards.

The server will likely just use some html templates in which it will replace some variables with strings and numbers. Easy peasy, both for the server and for the developer.

Since all the clients have to do the work, doesn't that result in a net increase in electricity consumption? Since most electricity comes from fossil fuels doesn't that in net hurt our battle against climate change?

Servers are probably a bit more energy efficient than most consumer devices, but in general it does not matter if you calculate it at A or at B. Somewhere it needs to be processed.

You were maybe thinking of processing once and then push it to thousands of clients? Those scenarios exists, but are the exception and not the topic here.

> Those scenarios exists, but are the exception

More like, they are the rule.

So by spending thousands of dollars on developer time we can save dozens of dollars on server costs? ;)

The developer time isn't higher than if it was server side rendered. And for some applications, like the ones I'm building, it would be impossible to do the work on the server.

I wouldn't say that it increases developer time. From my (sure, limited) experience of building both with Flask (Django-like, Python BE framework) and Svelte, the difference between developer time is negligable, if not in favor of building on the client - the component frameworks bring much more to the table, like scoped CSS, often better editor support for dynamic values in the HTML templates etc.

It is all a question, of how big you want to scale it.

Stack Overflow runs SSR with a half a dozen servers. How much more scale do you need?

A bit more, if the servers also have to handle media.

Eeeeeeexactly