We're at an inflection point with web application development. I've been developing web applications for 15+ years, and it seems like we're at a familiar place. The last time I remember being here was in the late 90s when the first server side MVC frameworks started becoming popular. Up til that point, most of the web applications were big lumps of code that handled a request and returned some html. For the most part, apps glommed together strings of html and sent back. Next we got to html with embedded code, and that was an improvement but still things were a mass. We had no concept of separation of concerns, no good way to organize our code. SQL was spread willy nilly amongst the angle brackets. It was baaaaad.
And then someone had the idea to apply the Model View Controller pattern to web development. Frameworks to do so abounded. I wrote my own, and then abandoned it when the world standardized on Struts, which was, at the time, A Good Thing. Web browsers in this era were fairly dumb, so it was clear where the code need to be for such a framework: on the server. The interaction with web browsers was strictly limited to a request/response cycle.
Over the past 10 years or so, the basic idea of a server side MVC framework has remained the predominant way to develop web applications. Variations such as component oriented frameworks like Tapestry and WebObjects have emerged, but the core idea of a server side framework that handles requests and returns responses and manages the UI and navigation for the application remains pretty much unchanged. If you look at Struts from 2000, you easily recognize many of the same pieces as you will find in ruby on rails of 2011. This for a good reason: server side MVC has been a great way to develop web applications for most of this time.
In the last few years, I've felt this start to shift. Web application UIs have gotten more interactive, dynamic, and sophisticated. The limitation of the request/response cycle during an application has started to feel positively archaic. Having to reload the whole page to see what happened when I attempt to perform an action just isn't cutting it when so many apps have proved we can do better. Server side frameworks have done their best to adapt and allow for richer UIs. But as clients get richer, it becomes clear that a lot more UI logic has to be on the client. Eventually it becomes unclear where to put what. Our clean separation of concerns begins to break down. We are back to a mess.
I'm going to suggest that it's time to do something radical: Let's stop.
Server side MVC frameworks have served us nobly, and we should thank them for their years of service. But it's time to move on. We need to embrace a different architecture for web application development. UI logic needs to be on the client. Communication with back end services and persistence stores can take place via RESTful HTTP calls with JSON payloads. Server side code doesn't go away, but it assumes a new place with more limited responsibilities.
This is a big change. A lot of our skills as web developers will need to be updated or replaced. But the ecosystem for building these kinds of application is booming. Many of the things that made developing applications in this manner painful a few years ago are dramatically different. Unit testing tools like Jasmine abound. A better javascript syntax thanks to coffeescript makes our code much more enjoyable to write. And frameworks like Backbone.js give us a clear separation of concerns while we build applications in this new way.
As I've started developing apps this way, I've been really excited by the results. The frustrations and foreboding sense of "this doesn't feel right" I found developing rich client apps with server side MVC is completely gone. It definitely took some time to change over, but I wouldn't go back.
There's a lot to learn though. To give you a jump start we've put together a two day training class so that you can jump in and be productive immediately. We hope that you'll join us in Cincinnati on September 8th and 9th.
