Old grumpy dev here.

Of course you don’t want the API built for data retrieval also generate the HTML structure for display in a single location. But chances are your application is the only consumer of that data, and adding a server-side or middleware component that retrieves the data and generates the display structure for your application is still easier and faster than using whatever framework or vanilla JS to turn raw data into a display structure.

You may be tempted to argue that downloading a few bits of data is better than downloading an entire display structure. This is countered by the additional time spent by the web browser attempting to render things on screen.

You could argue that creating a display structure in a service causes a dependency between that service and the data, that needs updating with any change requirement, so now instead of having to update the data service and the web page, you also have to update the display service. This is countered by pointing out that it wouldn’t make any difference: it also needs updating if the display is generated in JavaScript on the web page that shows it.

If you depend on the JS or CSS framework of the month to display your raw data, you don’t have decent control over things like accessibility and usability - you’re subjected to the whim of its vendor.

Good luck.

A much calmer explanation of this sentiment

After we finally got really good JavaScript support, it’s not entirely surprising that everyone went crazy with JavaScript. So it makes sense that now we start stepping back and reevaluate what genuinely needs to be JavaScript and what doesn’t. Especially now that HTML support has gotten so much better too.

Or skip things like react entirely and use something declarative like htmx, less “glue code” you need to write and the server response can itself kick off new client side actions.

This is the way.