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