I’ve worked on so many projects recently that were more complicated than they needed to be because they used JavaScript to generate HTML.
JavaScript is… Slower to load Slower to run More prone to breaking Harder to read and reason about Doesn’t actually look like the final output It’s inferior to just using HTML in nearly every way.
I’m not saying never use JavaScript, though. I think JS is great at augmenting and enhancing what’s already there, and adding interactivity that cannot (yet) but handled with HTML.
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.