> That layer doesn't go away with server-side rendering. It is always there, even if you don't use a REST API. It just gets fused with views. When I wrote my c

> That layer doesn't go away with server-side rendering. It is always there, even if you don't use a REST API. It just gets fused with views. When I wrote my comment I was actually thinking the same, so I agree with you here. However, I still think the (view) model is way closer to your business model without having to go through JSON (or similar) and without the hassle to ensure the client actually received what it expects. I'd argue it's way easier to change or debug in the general case. > Unless the front-end is written in pure HTML+CSS, this hypothetical simplification doesn't materialize. Also, you can't brush off or ignore the complexity added by templating engines. It depends on the application, but of course you will have a few highly interactive parts that needs JS/TS (although technologies like alpine.js/html can help here), but still not all models need to exists in the client. > I don't get what point you're trying to make. Even if you are the only client for that API, don't you still need to put it together and maintain it? Yes, I mean "elaborate" APIs, my point being that an API for a single consumer can be entirely focused on that consumer. I've seen a lot of people building very flexible APIs without the flexibility being needed at all. I'd argue that one is not tempted to do that as much when doing server-side rending.