FireFox 1.0 and the modern browser.
Here’s the general idea:
Have the server render views in pure HTML+CSS and view models as JSON—avoid any kind of server-side code.
Granted, you must be sensitive to a search engine’s inability to index in this scenario, so this should generally be used for pages where user-specific data is shown.
An interesting advantage of this pattern is the reduced coupling on the server-side component of the system. In fact, I wouldn’t particularly care if it was written in PHP or Ruby or whatever. As long as it could push down the appropriate HTML and JSON, I could easily have the browser take care of everything else.
Warning: If you do this, your HTML designers will love you. No server side markup in the views? Designers are in heaven. And for them to be able to test different aspects of the view by changing simple JSON files—all without having a local web server (IIS) or even a local database. Life can’t get any better than this!
Another advantage that I’ve talked about previously would be to pre-render JSON views into files and to store them on some form of CDN. In fact, you could potentially store your HTML views on a CDN along with pre-rendered JSON view models such that users would be unaffected by outages of your system—at least for the purpose of querying and viewing application state.
One of my primary objectives in programming is choice. I want to be free to adapt and innovate my system. Tight coupling is the enemy of choice. Once you’re coupled, you’re restricted in your ability to choose. This isn’t to say that you write so many layers of abstraction that you can swap anything and everything. Instead, it’s about making wise decisions relative to areas that have a tendency to change quickly.