Saturday, January 3, 2009

My clients are getting thicker and thicker: MVC implementation shift

Last week I stumbled over this interesting article on the potentially changing Model View Controller architecture implementations. (Sidenote: here's the more subtle distinction between MVC1 and MVC2 described. And here's an article on the ambiguity of the term and pattern MVC.)
An example logical diagram of MVC2 is shown below:


For quite some years, the general practice was to generate HTML as result of the View, with the browser rendering it and being the thin web client. These days though, more and more the web client is getting heavier ("fatter") because of all the Javascript being used for AJAX, SPI and, in general, more logic on the web client.
The article takes a look at the different approaches to MVC implementations:

  1. the HTML-only approach;

  2. the HTML+Javascript "basic" approach; some of the Model's "business logic" is duplicated on the client;

  3. the "AJAX" approach; partial views can be updated, the view consists of multiple HTML fragments, Javascript creates the View, not the application server;

  4. and the full-blown Javascript-only ("a la gmail") approach; Javascript in the browser creates the views, near-complete responsibility for the Model business rules in the web client (browser), the web client would be the Controller.

The approaches range from, at the one extreme end, the definitive "thin client", and at the other extreme end, the definitive "thick client"." Example frameworks that can easily facilitate the last option are Google Web Toolkit (Java to Javascript) and Pyjamas (Python to Javascript). Below GWT's architecture diagram is displayed. Note the (relatively) limited application server procedures, part of the Model, preferably only performing basic validation, security, etc.


The new MVC2 diagram for the above mentioned fourth approach would look something like this:

Included in the article is also how you could split up work in a team between people working on the View and Model parts.

I do not completely agree with the statement in the beginning of the article that says "The Web client takes care of keystrokes and mouse movements: the Web browser application itself is the Controller". I'm reading this as: the browser is the controller. Though, when you look at the first picture, that is not what the Controller is supposed to be.
But, in general the whole potential movement of going to thick clients is an interesting one to keep an eye on.
Other pros for thicker Javascript-based clients (not mentioned in the article) are:
  • Easier distribution of new versions than in the old days with fat clients like Visual Basic, where you had to make sure all clients got updated;

  • Easy opening up of your SOA webservices. The fat client could directly access them;

  • Easier mashup possibilities at the View layer via Javascript;

  • Potentially a large improvement in scalability: the client processing power is used as much as possible, the application server only performs several basic checks;

  • The Javascript generator/builder takes care of browser compatability.


Several cons are though:
  • Potentially quite significant longer page loading times when the Javascript all has to be loaded at once;

  • If not designed correctly, there could be significant extra network traffic;

  • Being dependent on the Javascript generator/builder when a browser is (not anymore) supported (though an opensource framework allows you to build it yourself if really needed).

8 comments:

Arnaud said...

Good presentation !
Was google the first to follow this approach ?

Techie said...

AFAICT: yes: GWT first release was on May 16 2006. The only other framework that is similar is Pyjamas, and that's clearly built (and based upon) GWT: "GWT was ported to python".

Anonymous said...

Bah. I think relaying on javascript alone
is quite silly because 1) javascript is just good for web browsers and 2) it can be turn off and so is pointless when publishing accessible content.

Script Uncle said...

It is good to find more people coming to these conclusions. It is quite a journey :)

Please see the SOFEA specification and Thin Server Arcitecture for similar thoughts;

http://sites.google.com/a/thinserverarchitecture.com/home/Articles

Also some recent talks of mine on the subject:

Tech talk at Google; http://www.youtube.com/watch?v=XMkIZZ7dBng

Talk at the SAPO Codebits conference in Portugal:

http://codebits.sapo.pt/intra/s/speaker/10

Cheers,
PS

Techie said...

@erob: definitely true. Though the % of users that have it turned off seem to be quite low, although there don't seem to be any official numbers: 1-3%, 5%, 6%, 10%, 10-13%.
Most mobile devices won't run Javascript either. Another big minus for going fully Javascript is that currently none of the search engines spiders can process Javascript, so your SEO could become a problem. Maybe the combination HTML + Javascript with graceful degredation (keeping both worlds happy) is the best solution then?

Anonymous said...

Good article I wouldn't recommend Peters 37 minute presentation unless your suffering from insomnia. Just get to the point.

Unknown said...

Every day I see more and more evidences that html-based web apps are a big kludge. Why are we writing apps using a limited document definition language along with a limited, half-fledged scripting language? Today we can easily write Swing (client/server) web apps and distribute them with Java WebStart. IMHO, It's a matter of time for desktop technologies to become the "frameworks of choice" to write web apps.

Matt Lourie said...

Good summary. The ubiquity of rich client platforms like JavaScript, Java, and Flex has made true client/server an attractive option for mass deployment. Another option to generating JavaScript is to use a framework like jQuery which makes writing complex web applications directly in JavaScript a viable option.