Sunday, July 10, 2011

Why it's the late Cretaceous for server side MVC frameworks

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.

Great post, one comment though. Its clear that more functionality will move client-side but to my mind it won't be an all-or-nothing proposition. I'm pretty convinced the future will be most sites having a mixture of the two styles. So some % of the content primarily driven by JS on the client making REST calls, and some % where most of the work is done server-side (augmented with a bit of JS).

I'm also not convinced it means the end of Rails etc, depends on node.js but I see no reason Rails and the other frameworks can't do a good job of the server-side aspect of this new world.

As the client-side has been beefed up in complexity, I think one major stressor (other than the skills gap) holding back adoption is the lack of DRYness between server and client. In the least, model definitions and validation tend to get duplicated on both client & server. If an application is going to try to seriously attain progressive enhancement, the scenarios for duplicated "functionality" abound.

My hope is that by the time evolution completes, that we'll have a good answer for addressing this logical duplication by running the same CoffeeScript/JavaScript on both the client and the server. I think Chris Powers' drumkit.js is a good first step in that direction.

I've started a totally client-side project with JSON calls to the server for data and jTemplates for rendering UI. Which was going great until I realised that google won't be able to index any of my site. What to do?

This http://code.google.com/web/ajaxcrawling/ exists but what about the other crawlers.

I've started a totally client-side project with JSON calls to the server for data and jTemplates for rendering UI. Which was going great until I realised that google won't be able to index any of my site. What to do?

This http://code.google.com/web/ajaxcrawling/ exists but what about the other crawlers.

I think if we put all the logic in the client side, as well as the validation our server will accept all data and it will be so easy to crack the application. How do we handle this without putting validation on the server?

@Douglas There's no way to avoid doing critical validation on the server - it's the central gatekeeper to your data. If you're using server side JS then you can share the validation code, otherwise, you'll need to duplicate some stuff.

Remember though, you may have different criteria for validation on the server and client, so don't necessarily view it as duplication of code. Ian Bicking had some interesting thoughts on this matter.

Don't forget about accessibility. I'm not 100% sure, but it's my understanding that accessible browsers are still not up to the task of AJAX, and a lot of sites are legally bound to provide access for those browsers. At this point anyway, sounds like continuing to develop the AJAX layer /in addition/ to the server-side layer.

@TimBailey99 - the answer might be NOLOH. I have a put a site live using this platform and it provides a very nice and easy way to provide excellent SEO, provides powerful yet easy to implement Ajax capabilities, driven by its server programming model (yes, I did say that) and all the benefits and security of using a server side approach - http://www.noloh.com - give it a look. It's a fantastic way of developing web applications

Nice work Chris! Given that I've written way more Javascript in the past couple weeks than I have Ruby I've been thinking about this too. One possible way to overcome the duplication of models is to create all the models on the server and have model methods to specify what you want to expose to the client. Then the server could serve the proper Javascript for the models.Just a quick thought off the top of my head, might be worth looking into.

I'm also notDiablo 3 items convinced it means the end of Rails etc, depends on node.js but I see no reason Rails and the other frameworks can't do a good job of the server-sideCheapest wow gold aspect of this new world.

China, a quick creating nation of nowadays has a history dating over 5000 years. These 5000 years is often found in ancient scriptures. The fact is Chinese Fashion, Ancient China was a single on the most cosmopolitan civilizations. This really is evident from the different components that make up its culture. A rich culture was depicted in the ancient Chinese clothes and dresses.