Years ago I considered Javascript to be more or less of a joke as a language. At the time browser implementations made creating a consistent implementation both dangerous and time consuming. Time passed and several very significant things happened:
- FireFox 1.0 and the modern browser.
- Google Maps
- jQuery
- Web-scale loads
Because of these developments, much of my recent work has been able to leverage Javascript more fully thus making the browser an integral part of a fully distributed system. Specifically, with Javascript we can leverage the browser to handle portions of the load and to enhance the user experience. Ever noticed how during intermittent network connectivity, Gmail will let you know that it's trying to send your email?
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.
- Use a Javascript templating engine such as jQuery Templates to bind the JSON model to the view.
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.
Conclusion
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.
By making views pure HTML with CSS and by leveraging Javascript templating to integrate the view model, we have significantly reduced any requirements on the server for performing this work for us. Server side <% %> tag soup? Gone. No need to worry about Razor. In fact, the server side becomes very naïve and almost an afterthought in the entire process. The result is that we really start to focus on the total user experience and ultimately delivering business value instead of focusing so closely on the technical aspect of the business.