[exelius]

The "right" way to do this (edit: this is essentially assumed by the article, so I'm not contradicting it) is to build static sites and use JavaScript to pull in any dynamic information. You run data services that output JSON, then the JS on the page calls those data services and renders the views.

This still allows you to reap the benefits of static content (namely CDN distribution / caching) while still maintaining some dynamic content.

But basically, you do it this way to avoid pulling data that isn't user-specific from the database. It's far more efficient to build a header + page + footer once at build time than to have every client have to do that on access -- even if you have 100+ variations of your site that need to be compiled and updated on any change in the shared content. Storage and compute resource are trivially cheap if they don't scale exponentially with number of users.

Yeah, it's more work for your developers, but it saves your DBAs a LOT of work by reducing the volume of data served from the database. And at the end of the day, it's full-stack effort that counts -- I'd rather have my developers spend 2x the time to build a system than have my DBAs fighting fires because the site went down. With a static site, you can set it to read-only mode if the traffic gets to be too much, and the static content will be handled by the CDN (which can almost certainly handle any load).

[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.