> Another (AJAX) HTTP request + rendering the returned data on a tiny mobile phone is faster than one HTTP request for the entire webpage and having dedicated m

> Another (AJAX) HTTP request + rendering the returned data on a tiny mobile phone is faster than one HTTP request for the entire webpage and having dedicated machinery pre-render the content for you? I don't think so. He does talk about this point later on, but which is it? Client-rendered JS apps are, or aren't fast? Very large generalization, it depends on the specifics of an implementation. Plus this isn't as scaleable since you're consuming CPU cycles rendering views on the server. > The solution is very simple: render all the data on the server, and progressively enhance subsets of your app with JS, by overriding the defaults of the rendered page. It's literally like we're discovering DHTML all over again. So you're telling me to write a web app that consists of: A Server-side application, multiple page-specific JavaScript "widgets", and an API endpoint for AJAX communication. That doesn't sounds very fun or efficient for the programmer. It's is taking a step back in time in terms of developer happiness, and application complexity (and possibly efficiency but that's implementation specific). Also, what about saving UI state?? Good luck with that... What sounds better to me is a single RESTful interface and a JS application that renders all of your views. It does have it's downsides (SEO + tin-foil hat people disabling JS), but it's a much more elegant solution.