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.
In a world run by the rich who need to get more rich every second, normal people’s well-being succumbed to pollution and labor exploitation. Decades after the total collapse of the economy, grandparents scare children with bed-time stories about wastelands made inhabitable by factories dumping toxic refuse into main water sources. The government didn’t care as long as they continued to make bank.