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.


TerminatorJoe said...

So what does this mean for the future of Rails dev? Does DHH need to find a new gig?

Matt Darby said...

I fully agree on all accounts. We're starting to witness the third epoch of the web (static HTML, Server Side MVC, and now true Client/Server). It's definitely time to retool.

skilldrick said...

Great post!

I fully agree - I've blogged a few times on this recently: The end of progressive enhancement revisited and JavaScript, JSON and modern web MVC.

Colin Jack said...

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.

Andrzej Krzywda said...

It's worth pointing out that MVC is the MVC that we know from desktop apps and can be applied to client-side easily.

Server-side uses Model2 architecture and can't use MVC without some extensions like websockets.

Anyway, great post!

Justin Searls said...

Terrific post. I'm jealous that I didn't write it myself.

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.

TimBailey99 said...

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 exists but what about the other crawlers.

Any reccomendations?

TimBailey99 said...

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 exists but what about the other crawlers.

Any recomendations?

Douglas said...

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?

skilldrick said...

@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.

dob said...

I can see this working for a 5-10 screen app but not working at all for a 50-500 screen app. Does everyone agree with me?

yitznewton said...

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.

Gazley said...

@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 - - give it a look. It's a fantastic way of developing web applications

Adar Wesley said...

Loved the post! You stated everything I believe regarding development of modern Web Applications.

Your post came at a good time too. Just a few days ago Scott Hanselman blogged about JavaScript being the assembly language of the web. I believe your post is a good contra to his claim.

I truly believe that client logic should be developed in client technology and executed on the client.

You mentioned backbone.js as a client framework. I personally love the workings of knockoutjs

Happy hacking :-)

Adar Wesley

Joe Fiorini said...

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.

@yitznewton - For accessibility, look at WAI-ARIA ( It's a W3C standard for developing accessible rich internet applications (exactly what we're talking about here).

Błażej said...

Ahem... Isn't this what GWT is all about?

inside-out boy said...

been doing client side mvc in gwt 3 years now

xinag zhong said...

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.

Ming Zhang said...

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.

geoul oh said...

Read all the related Posts:

Basic of VBScript Language for QTP

Introduction to QTP (QuickTest Professional) Part2

Introduction to QTP (QuickTest Professional) Part3

Introduction to QTP (QuickTest Professional) Part4

Basic of VBScript Language for QTP


ISTQB Practice Test Part 1
ISTQB Practice Test Part 2
ISTQB Practice Test Part 3
ISTQB Practice Test Part 4
ISTQB Practice Test Part 5
ISTQB Practice Test Part 6
ISTQB Practice Test Part 7
ISTQB Practice Test Part 8
ISTQB Practice Test Part 9

le huong said...

Interesting point of view and I agree with most of what you say.You've made some valid points and I think you're spot on.

aion accounts

le huong said...

I like the article you wrote here; it is very informative and useful for the internet users like me. I will come back to read more your posts and I have bookmarked your post as well

interlocking services toronto

adeoe said...

So what does this mean for the future of Rails dev? gw2 gold Does DHH need to find a new gig?

AntoL-Nyo said...

HD kaliteli porno izle ve boşal.
Bayan porno izleme sitesi.
Bedava ve ücretsiz porno izle size gelsin.
Liseli kızların ve Türbanlı ateşli hatunların sikiş filmlerini izle.
Siyah karanlık odada porno yapan evli çift.
harika Duvar Kağıtları bunlar
tamamen ithal duvar kağıdı olanlar var

AntoL-Nyo said...

Ben istanbuldan selda 22 yaşında konfeksiyon içşisiyim Amatör Porno sizleri bekletmeden hemen hikayeme geçiyorum.. Biz 5 katlı bir binanın en üst katında yaşıyorduk ve bir öğlen paydosunda sevgilim beni Anal Sikiş aradı evdeydim çünkü evle iş yerim arasında 2 dakika bile yoktu.. Bende Asyalı Porno sevgilime benden telefon beklemesini söyledikten sonra evin durumuna baktım evde kardeşlerim ve annemin Esmer Porno birkaçtane arkadaşı vardı bu iş imkansızdı tekrardan düşündüm ve çatı katı aklıma geldi sevgilime telefon açıp çatıya çıkmasını ve Fantazi Porno beni beklemesini söyledikten sonra telefonu bir süre elime almadım anneme işe gidiyorum dedikten sonra Gay Porno hemen üst kata çatıya çıkıp sevgilimin
dudaklarına yumuldum az bir süremiz Götten Sikiş vardı ve çok istiyordum onu hemen önünde diz çöküp sikini çıkardım kocaman olmuştu bile... Özlemişti beni HD Porno bitanem başladım sikini yalamaya kafasını öpüyor onu çıldırtıyordum sevgilim saçlarımdan tutmuş ağzımı keyifle sikerken çatı katının kapısı açıldı toparlanamadan Lezbiyen Porno komşunun şişman oğlu efecan gelmişti ben dizlerimin üzerinde sevgilimin Liseli Porno siki ağzımda yakalanmıştım hemen bu halimizi gören komşu oğlu Sarışın Sikiş kaçarcasına gitti.. Sevgilim bir süre güldükten Türbanlı Porno sonra bu şişko neden kaçtı korktu herhalde onu sikicem sandı galiba dedikten sonra bir kahkaha daha attı ben sevgilimin Türk Porno sikine deli gibi saldırıyor yalıyor emiyordum boşalmasını istiyor Zenci Porno sütünü içmek istiyordum sevgilim ağzımı sike sike boşaldı hepsini yuttum bir damlasını ziyan Porno etmedim ve sevgilimle vedalaşıp ayrıldık... Ben her defasında sikiş yapmadan önce yazporno diye olan türkçe siteden Porno izle bölümüne girip seyrediyorum azdıktan sonra şahane sikiş ile gözleri kamaştırıyorum.

Derek Karson said...

hi!,I love your writing very so much! I require an expert in this space to solve my problem.