That's true. But that's only really a concert if you're building an SPA. If you're not, having multiple pages is generally faster than running some js framework to reload parts of the page. Plus that you get the benefit of every state combination having it's own URL. You don't need to write any custom state reconstruction code.

This was the original design of REST as applied to the web. It was explicitly designed in such a way that it was forbidden to reload parts of the page. This makes it so that every state has it's own URL and you therefore can link to every state. Deep linking if you wish, for all of the web.

JS can update the DOM dynamically.

Nothing prevents the main response from being served as regular HTML and subsequent XHR request for some parts of a page being JSON or some such data format. In fact I bet that sending server-side rendered HTML is faster than sending a full structured page as JSON which has to be decoded, parsed, and then converted to HTML.

I run a popular app (native ios and android) and a web version. I find having A single json serving api much easier to maintain. The frontends are isolated projects. The backend is just a simple layer with static data served as json. If you would have static html it means you need to update all static files whenever a ui change is needed. Makes it overly complicated. Caching becomes also a challenge and the so does the performance. Currently just running a few Hetzner instances to serve 50k requests per second. That would be really hard with a server side rendered html.

> If you would have static html it means you need to update all static files whenever a ui change is needed. Makes it overly complicated

We do use a templating engine and separate CSS files, so no, not at all, all static files does not need updating on every change.

> Caching becomes also a challenge and the so does the performance

Not at all, not even on black fridays.

> That would be really hard with a server side rendered html.

Why do you pose that hypothetical when our real-world experience is easy?

Do you build each interface with different tools (e.g. Swift, Java, and React), or one of the unifying tools (Flutter, React Native, etc)?

Then you're stuck with two kinds of templating.

Reminds me early AYAX days.

Around 2005 was the first time I "accelerated" a website by requesting the whole page in the background and swapping out what had changed.

We eventually trimmed what was returned a bit, but just getting rid of the page transition was 90% of the work.

You can still return html partials from your endpoints and use htmx to swap content without a full reload :)

yes, but then it’s not one request per page

Only if there’s an update - htmx will encourage you to render full html pages but still gives you the ability to do in-place updates which is what most folks think a JS front end with a json Api backend and client side rendering is needed for.

HTMX can swap multiple DOM elements from a single HTTP response

https://htmx.org/extensions/multi-swap/

In that case you can just parse the DOM clientside and insert it into the page.

The is exactly what HTMX does and it works: allow returning a HTML response and statically annotating a part of the DOM to be replaced with that.

Granted, this requires JavaScript on the front end, but it's a framework that can be shared between different websites, so you're not writing any custom JavaScript for your site.