[Albright]

Using JS to present data moves the work of generating the display of that data from the build process, as with "pure" static site generation, or from server-side code, as with a standard CMS, to the client, where it is most likely to fail in unpredictable ways due to variances in browser JS or CSS engines, network performance, browser extensions, etc, etc.

But given that the concept of progressive enhancement seems to have been completely lost on the latest generation of web developers, who cares, right?

[exelius]

Well, the key here is that any non-JSON data you pull from a URL should be static. That means it can be cached, and the client should only be pulling a small amount of data that varies based on their account.

I wouldn't write an interactive web application this way, but for sites that are mostly content the approach works fine. You still have to test on multiple browsers, and you still have to write code that handles the differences in browsers/engines/etc. But your servers are doing less work, and the content reaches the customer faster. It's still up to you to optimize your JS (though I guarantee most tracking cookies are taxing JS far more than rendering a few divs will).

[Albright]

> the content reaches the customer faster.

Does it? Is it really slower for your customers to download a server-generated page than for them to download a static page, (probably) download a JavaScript file embedded in the page, execute the JavaScript, then download and process server-generated JSON?

[exelius]

Considering they're likely also downloading JavaScript and executing it when using the server-generated page, yes. Let's not pretend it's possible to do everything on the server side. Just now instead of compiling the page in real time when it's accessed, we compile large parts of it long before the user requests it.