I find this advice overly simplistic to the point of being completely misguided.

Let's take the table example. Sure, you can fetch an HTML snippet and insert it directly in the DOM tree with innerHTML. But then, how do you handle:

  1. Formatting based on client-side preferences (e.g., formatting dates based on the client's time zone)
  2. Changing the sort order (e.g., by clicking a column header)
  3. Filtering rows (e.g., by typing in a search box)

And yes, if you really want you can make the server generate custom tables by passing query parameters of the form: ?sort=price&tz=Europe/Berlin&query=foo, but that has several downsides:

  1. You're now sending potentially privacy-sensitive information to the server.
  2. You have to make a roundtrip for every change in any of the parameters, which is slow and wastes bandwidth and server resources.
  3. Arguably the worst: your presentation logic is now spread between the frontend and backend, instead of being concentrated in the frontend, where it belongs.

I can think of two rebuttals. One: what about the simple case, though? Isn't client-side formatting overkill in that case? Yes, it is, but people use it anyway, because it's generic: it works well for simple and complex cases alike. It's easier to learn a small set of well-understood general solutions than a large set of niche solutions.

Two: what about performance? node.innerHTML = 'bla' is faster, isn't it? Yes, it probably is, but for small-to-medium-sized tables the difference won't be noticeable, and tables that are so large that the time it takes to render them begins to matter, it's probably a better idea to reduce the size of the rendered page anyway, e.g. by introducing pagination. So even if we don't need any fancy features, cases where the "fast" solution is clearly beneficial are rare.