I think the "architectural principle of the internet" is not what you suggest. Years ago, I pushed as much work onto the client as possible to reduce the workl

I think the "architectural principle of the internet" is not what you suggest. Years ago, I pushed as much work onto the client as possible to reduce the workload on my servers. Now, people complain if you push too much work onto their phones. They want the server to do the heavy lifting so the app can be more responsive on their low-powered mobile client. "The internet" doesn't define how much weight each end of a connection should bear. It doesn't really even dictate that there are only two ends. Should a webapp have a braindead REST api with a select, insert, update, delete for each table of the underlying db model and have the client make 1000 nested calls to the server to render the simplest thing? Or should the server api be much more sophisticated so that a single api call can provide all the information required for the render? There's no one right answer just because "internet".