The suggestion to have the server return the table directly starts bringing presentational concerns into the backend, which I am not a big fan of.

Having the server return plain JSON means the APIs can be reused across products effortlessly and also means that all style changes can be done in the same codebase.

I get reminded of how important this is every time I get to work on an old project that has APIs return HTML that is then being inserted into the DOM by something like jQuery. Figuring it out and updating it is typically a huge mess.

If you control the full stack like in the article, you could have a server backend server the JSON, and another backend taking that and serving HTML, if you wanted.

Edit: This could still be way simpler than the "hydration" approach which is so popular.

> Having the server return plain JSON means the APIs can be reused across products effortlessly and also means that all style changes can be done in the same codebase.

How many products actually share the same server backend? Do they all organise the same data on the same pages? If no, then you already need per-product APIs to avoid making O(N) fetches from the client side Having your backend be aware of what is being presented is rarely a bad thing