Blurring of MVC lines: Programming the Web Browser.

When HTML first came out, browsers could have been called "Application Thin Clients", if the buzzword had been in use at the time. The introduction of javascript made it possible to execute code on the client, and this turned browsers into something much more than just a "display" mechanism.

Before Javascript, Web application development was simple: everything was done server-side. The concept of MVC - Model View Controller - was easy: the HTML was generated, and that was the view. With Javascript being a full-blown programming language, the lines are being blurred between which code is responsible for the View, the Controller and even the Model. The resultant split of responsibility across client and server in wildly diverse programming languages is driving many developers to alternative technologies such as Flash, and causing headaches for those Web developers who remain.

The key components of the solution - to allow the developer to create MVC applications in a single programming language, where at least the "View" source is extracted and compiled to Javascript and HTML - actually exist and are used in production environments, thanks to Google Web Toolkit and Pyjamas. RubyJS is well on the way, too.

Here is a definition, wikipedia, of what MVC is:

Model-view-controller (MVC) is both a design pattern and an architectural pattern used in software engineering. Successful use of the pattern isolates business logic from user interface considerations, resulting in an application where it is easier to modify either the visual appearance of the application or the underlying business rules without affecting the other. In MVC, the model represents the information (the data) of the application and the business rules used to manipulate the data; the view corresponds to elements of the user interface such as text, checkbox items, and so forth; and the controller manages details involving the communication to the model of user actions such as keystrokes and mouse movements.

This article will take a look at the different approaches to MVC web development - the HTML-only; the HTML+Javascript "basic" approach; the "AJAX" approach and the full-blown Javascript-only ("a la gmail") approach to Web application development. The approaches range from, at the one extreme end, the definitive "thin client", and at the other extreme end, the definitive "thick client".

Then, a number of frameworks and programming languages will be examined: a comparison given of some of the best and some of the worst. Whilst, ordinarily, such a comparison would look like a total bitch-fest, in the context of this article it can be highlighted with abundant clarity why it is becoming so wildly inappropriate to use certain programming languages for Web development, and why the use of frameworks - even if written in inappropriate programming languages - is so vitally important.

HTML as a "display" mechanism: Thin Client

Taking a traditional HTML-only approach to MVC is very very simple, and easy to do. There are dozens if not several hundred Web frameworks that can be used.

• The Web Server will be responsible for interacting with the Data in the Model.
• The Web Server will be responsible for enforcing the Model's business rules.
• The Web Server will be responsible for creating the View that will be displayed on the Web Client.
• The Web client takes care of keystrokes and mouse movements: the Web browser application itself is the Controller, and the "standard" web behaviour - HTTP GET triggered by Hyperlinks, and HTTP POST on Forms - is the communication mechanism between the Web client and the Web Server.

In this "Thin Client" type of MVC approach, much is taken for granted. It is often so simple that people wishing to create quick web applications will ignore the MVC concept entirely, and thus also ignore of some of the basic rules of Web security and robustness. SQL Injection attacks become commonplace; data is not translated into HTML correctly; Unicode and UTF-8 character set incompatibilities cause massive headaches.

The more experienced Web developers utilise MVC frameworks that not only take care of these issues but also go one step further, regarding Data handling. Typically, the best frameworks will abstract out access to the underlying database, providing a flexible and powerful but still relational way to manipulate data.

HTML plus "basic" Javascript

Once people become familiar with the basic HTML-based MVC approach, the default behaviour of the Web browser quickly becomes tiresome, lacklustre and time-consuming. As the "basic" HTML approach is at the extreme end of the "Thin Client" approach, all incorrect or even empty data fields must involve a round-trip to the server in order to validate the input against a Model's business rules.

Having to submit data to the server each and every time, resulting in a new View being generated, into which any errors are inserted advising the user on how to correct their input, is not only tiresome but also can consume considerable Web Server resources. This is where Javascript started to come to the rescue.

Javascript is typically added to perform some of the more "basic" Model business rules. Here are some examples which are quite commonplace:

• "this field may not be empty"
• "this field must be alpha-numeric and longer than 6 characters"
• generation of a javascript popup that allows a date to be entered using a pretty widget (instead of three listboxes which would allow 31st February as a valid date, or a text-entry field that could result in US/Non-US day-month ordering ambiguity)
• switch the "Submit" button on-or-off, depending on whether other fields have been successfully filled in to some "basic" degree of satisfaction.
• List-boxes that are enabled, or their contents modified, depending on whether a checkbox or a radio button is selected.
• Enabling or disabling of entire areas of the View, depending on prior input.

All these, and many more like it, are examples of the application of basic Model "business" rules. The application of such simple rules at the client end does not remove the need for duplicate-checking of the same rules on the Web Server - however, the useability of the application is greatly enhanced due to the reduction of the time delay between users entering data and them finding out some of the basic mistakes; and the Web Server's load is reduced.

It's worth emphasising that an incredibly common mistake that novice developers make when getting involved with HTML+Javascript is to think that the implementation of Model "business" rules client-side somehow means that the same business rule validation does not need to be executed server-side. The worst possible offence of this kind is the one involving checking of passwords. Experienced developers may laugh at this kind of mistake, but a search through forums showing people extolling the virtues of their anti-spam javascript-only "Forum and Blog" protection mechanisms are despairingly common.

Also, at no time does any developer in their right mind even contemplate duplicating the entire set of the Model's "business" rules. The reason for this is very straightforward: Javascript is a terrible language to program in (its syntax is too obtuse, despite it being incredibly powerful). Even if it were an easy language, it would still be a nightmare to implement a dual set of Model "business" rules - one set for execution on the Web browser and another for execution on the server.

So, typically, a web developer will make a half-hearted attempt to satisfy some of the more basic business rules (non-empty fields) and communicate the required corrections to the user, or simply provide an enhanced View that cannot allow an "invalid" data entry. Then, on the Server-side, given that the Web browser is now responsible for ensuring that the business rules have been enforced already, a quick double-check can be made purely for security and data integrity reasons, and a very sparse error message returned by the Web Server.

In this way, some of the Model "business" logic that was the sole and exclusive domain of the Web Server now moves onto the Web "Client".

The lines are already becoming blurred...

HTML and the AJAX approach

Some of the more innovative Web developers had noticed the potential uses for XMLHttpRequest as far back as 1996 - however it has taken the rest of the Web development community some considerable time to catch up. XMLHttpRequest is a means by which, in Javascript - i.e. under programmatic control on the Web client - additional HTTP content can be retrieved from the Web Server.

The significance of this feature cannot be underestimated, as the level of interaction with the Web Server is suddenly no longer limited to when the user presses "click". in MVC controller terms, in both the basic HTML and the basic HTML+Javascript approaches, communication between the View (displayed in the browser) and the Model (implemented on the Web Server) was restricted to when the user pressed a key or pressed a button.

In some of the more advanced HTML+Javascript approaches, the normal "submit" conventions could be broken or augmented, by using javascript to activate the "submit" button - on a timer, or after certain of the "basic" business logic rules were fulfilled. but nothing in the standard HTML+Javascript approaches compares to what AJAX is capable of.

The key difference between standard HTML+Javascript and AJAX is that the Web Server can be contacted independently of the View - behind the scenes of the current "View". By using the AJAX approach, a whole range of new possibilities are opened up:

• Partial Views can be loaded: a Web Site can be loaded in sections; HTML fragments downloaded independently, and assembled into the Web browser, using Javascript. A simple approach would be to emulate the concept of "iframes", without the disadvantages that iframes brings.
• User-input can be validated continuously or on-demand, without having to submit the entire "Form". Partially-complete or completed fields can be individually submitted, using an AJAX POST, to the Web Server, to be validated against the Model's business rules.
• New menu options or list-box values can be loaded, dynamically, depending on user-input in other areas of the View, using AJAX, instead of having to load the entire set of options in one View.

All of these techniques save considerable amounts of time, and enhance the speed of the application. The latter option mentioned above is one which deserves further attention. Imagine a large menu tree or series of hierarchical list-boxes, comprising some 20,000 options in total, each option requiring 100 characters of HTML text to be displayed. It is inconceivable that a web page of some 2 megabytes in size would be tolerated by either the users or the Web administrators, as its generation could take potentially minutes of Server time to create, as would its rendering. By using AJAX to load only the tree-content that the user is interested in, the amount of data loaded from the server is kept to a minimum, and the response time comes up to a more acceptable range.

The implications for the MVC framework are, however, that suddenly, a lot more of the Model's "business rules" fall into the AJAX-solvable realm; also, the creation of the "View" is suddenly considerably more complex. Suddenly, the "View" is no longer being generated as a single chunk of Server-side-generated HTML; the "View" is "constructed" from a multitude of HTML fragments or, in some cases, raw data.

At this point, it's worthwhile specifically going over one possibility which AJAX opens up: that of separating the "View" mechanism from the actual data to be displayed in that view. In the case of the AJAX-driven menu options, list-boxes and tree-views, there are two ways in which a programmer could implement such systems. The first is by asking the Web Server to generate HTML fragments, which are retrieved by an AJAX query; on receipt of the response, the new listbox, menu option or new tree-view HTML content is substituted into the Web browser "View". The second technique is to retrieve the data as a text file, an XML document or some other easily-parseable format. Then, through the use of Javascript, the Web Browser's "View" is manipulated; a new List-box created where its options are programmatically filled in by manipulating the DOM model of the Web browser.

Suddenly, Pandora's box has been opened, where the server is no longer even responsible for creating the View - that now becomes partly the realm of Javascript, in the Web Browser! Whereas in the HTML+Javascript approach, it was conveniently possible to perform some of the Model's "business" rules validation in the Web Browser (using Javascript), AJAX begins to allow for the supposedly-convenient possibility of creating Views in the Web Browser, as well!

Faced with this additional burden of complexity, many Web developers quake and quail at the tasks that they are asked to consider, with the threat of being "left behind", with the "Web 2.0 revolution" closing in. With "all sticks and no carrot", the age-old simple MVC approach that they were comfortable with has been turned into a minefield involving complex multi-layered application interactions and a language that they really don't want to get involved with is forced upon them: Javascript.

Many Web MVC-based frameworks try to help the developer out of this blurred-Model, blurred-View quagmire by providing integrated AJAX libraries: the problem with such "help" is that the burden of writing the obtuse Javascript is moved from the Web Developer to the Framework developer, with no obvious benefit to either, and several down-sides for both.

Many developers try to plump for a fully-grown all-singing, all-dancing Javascript library such as mochikit, jquery, prototype or extjs, in an attempt to either augment the "View" with javascript, or to help them work-around the terrible obtuseness that is Javascript. What these libraries do for such developers, as far as the MVC model is concerned, is get them deeper into the mess, as they not only introduce a monstrous additional dependency with which they will never fully become familiar or confident with, should it go horribly wrong or not be up to the task (thus forcing the Business to adapt to the technology - the absolute Cardinal Sin of I.T. development), but also the split between the programming language used by the Web Server, and that of the Web Client deepens yet further. On top of that, the additional burden of the more feature-rich javascript libraries, such as extjs, adds an intolerably-high load-time to each and every single page on which a particular widget is utilised.

As a result, it's no wonder then that many developers abandon AJAX and "traditional" web development, and go for Adobe Flash and Silverlight, both of which are proprietary and have significant disadvantages, or they go for a Java browser plugin, which is just as dodgy.

The options, therefore, are pretty limited... or are they?

Full-blown Javascript-led Development

If it wasn't for the fact that programming in Javascript is so obtuse, the idea of handing complete responsibility for "View" generation and near-complete responsibility for Model "business rules" validation to the Web Browser would make perfect sense.

Here's what the ideal scenario would be:

• The Web Server would be responsible for interacting with the Data in the Model, and providing the data on-demand via AJAX.
• The Web Server would be responsible for enforcing the Model's business rules at a basic level, doing security checks, double-checking data submission integrity checks, and providing sparse error messages. The Web Server's job does not have to involve generation of or modification of the "View", but it does at least have to communicate the error messages to the "View".
• The Web Client would be responsible for enforcing the Model's business rules, where literally all of the business rules are written in and enforced in Javascript (confident in the knowledge that integrity checks and security checks will be performed server-side).
• The Web Client would be (mostly) responsible for creating the View that will be displayed on the Web Client, to the user, which will include the display of user-friendly error messages and advice, should the Model's business rules be broken.
• The Web Client would still the Controller - albeit a much enhanced and augmented one, as a full level of user-interaction, thanks to Javascript's ability to tap fully into the Browser's Event handling system, would now be possible.

In other words, not only is the MVC roles of the Web Server and the Web Client almost totally reversed, but also, the Web Client itself is beginning to sound far more like a full-blown Desktop Application than a "Web" Browser.

If it wasn't for the Javascript, the above would be a much more appealing proposition, and that's where tools like the Java-to-Javascript compiler, Google Web Toolkit and the Python-to-Javascript compiler, Pyjamas come into play.

These two fully-functioning development frameworks are, in the light of the present AJAX mess, absolute god-sends. They allow the developer to program in Java or Python, respectively - where the Java can even be developed using the standard "Eclipse" interface - and then "compile" their source code into Javascript, for execution in the Web Browser.

Nearly 100% of the language features of each of the respective source languages, Java and Python, are available to each of the development environments (Pyjamas at present cannot compile Exceptions, for example). GWT is impressive for its size and its userbase; Pyjamas is impressive for how little code is needed to do the same job. A ten times reduction in code provides almost exactly the same features as GWT: 8,000 lines of python instead of well over 80,000 for the GWT user-interface library, alone.

The one thing that developers who have never heard of GWT or Pyjamas cannot quite get their heads round is the fact that the Java code or the Python code is NOT running natively in the web browser: that's only possible with technology such as Hulahop or PyXPComExt with the PyDOM extension added as well.

Pyjamas and GWT are COMPILERS. The output from these COMPILERS is JAVASCRIPT. The JAVASCRIPT runs in the Web Browser, NOT the source code (python or java) from which the Javascript was created.

Included with each of the two toolkits is a respective library suitable for manipulating the DOM model of a Web Browser, and, then, on top of those is an additional library that provides a Widget Set that is incredibly similar to a Desktop Widget set. Thanks to these widget sets, the traditional HTML-only Web browser, which was very much a "Thin Client" affair, is fast becoming a proper "Applications Environment", albeit one which has restricted Internet access (XMLHTTPRequest is the only gateway to the rest of the world).

So how do GWT and Pyjamas interact with Web Servers? The answer is: as the code is compiled into Javascript, in exactly the same way that you would as if you were writing an ordinary HTML+Javascript or an ordinary HTML+Ajax application - by using HTTP Get, HTTP Post, or AJAX.

The fact that the developer can coincidentally write their application in the same language as the one they are writing the back-end Web Server in lifts a massive burden from their shoulders. The fact that they can write the front-end code in Python or Java does not force them to write the back-end Web Server in Python or Java: it's just a nice convenience.

However, the tantalising possibility now exists to have both the client-side source code and the server-side source code in a single file. Even a simple perl or awk script, and a syntax similar to or simpler than that of yacc or boost would suffice, and make the development process that much easier to get back to the MVC roots.

Here is the "ideal" world scenario, which does actually exist, in the form of a very simple but currently proprietary project called "Unity":

• A developer writes front-end "View" code in classes and modules, in python code, in specially-marked sections.
• The Model "business logic" rules are also written in python, in separate classes and functions, again in specially-marked sections.
• Functions whose purpose is to submit data, after it has been validated by Model "business logic" rules, are similarly marked.
• The Model "data-driven" code are separated out into classes and functions, in specially-marked sections of the same source code file.
• a "compiler" pre-analyses the source code file, looking for the special markers:
  • "Views" and "Model Business Logic" are split out into one file, which is handed to the Pyjamas Compiler and turned into Javascript (for execution in the Web Browser). The "data submission" functions are turned into JSONRPC client functions, which, again, are turned into Javascript AJAX and JSON Javascript functions, by the compiler.
  • "Model data-driven" code is separated out into another file, and stub templates are added which turn the data functions into a fully-operational cherrypy JSONRPC-enabled Web Server application.
• The compiled Javascript is made available to the Web Server.
• On execution in the user's Web browser, the application performs AJAX-based JSONRPC client calls to the cherrypy Web Server to load the application "Model Data" into the "View".

Several steps in this process have been missed out, but it should be abundantly clear that the traditional "MVC" is back with a vengeance: the blurred lines between which bits of code are responsible for "Model business logic" validation are gone, and the blurred lines regarding which bits of code are responsible for generation of the "View" are also gone - but not completely. It's up to the developer to decide how far they want to deviate from the traditional 'HTML' style of display / information rendering. Not everybody is comfortable with the use of Widgets that are executed as Javascript to do the job that HTML used to do (even if it's behind a javascript framework such as mochikit, extjs or prototype), and fortunately, both the GWT and the Pyjamas frameworks do an extremely good job of supporting and interacting with straight HTML (investigate the HTMLPanel widget, for example, for details).

All in all, as the Unity Project shows, writing in a single programming language is a far saner approach to Web programming than the present half-way-house double-languaged nightmare that is so prevalent at the moment.

Nightmare Languages

Finally, against this background, it's worthwhile re-emphasising just how piss-poor some web development languages and approaches are, compared to the Unity Project's approach.

php is the "language of choice" for the majority of web development, and it can be described as "The Visual Basic of Free Software" for very good reasons. Visual Basic gets a poor rap, because it is so easy to write bad code with. It takes years to become properly familiar with and proficient in Visual Basic, and php is no different. By the time a developer is familiar with php's rich and wonderful methods for self-mutilation, their lives have become so degraded that they wish they had never become programmers.

Why?

php was developed at a time when there really weren't any frameworks: the choices for Web development were drastically limited. Python was still unheard-of; Perl was about the only major programming language, other than ASP, that could remotely be contemplated; CGI-bin programming was the "norm".

php provided the incredible and exciting feature of being able to embed a scripting language into the HTML source code - HTML being considered to be an actual programming language, when in fact it is a markup mechanism. In MVC terms, and, very importantly, in the traditional HTML-only MVC Web Development environment, where Javascript too was still not that well known, php was a welcome breath of fresh air.

However, php was developed with very little foresight for the potential for abuse; its syntax is arcane; the fact that it can be mixed in with HTML quickly became abused - badly. Unfortunately in particular, the fact that the PHP code could be embedded into HTML led non-programmers to believe that it was easy to program a comprehensive web site.

Thus, unskilled and untrained people started to develop web sites with blatant disregard for the complexities and subtleties of web development, which had led more experienced programmers to come up with things like MVC frameworks.

As the number of php programmers has increased, so has the amount of bad code, and the "legacy" of the poor design of php has burdened the designers of the php language with some quite serious problems. The most notable of these is the fact that many php programmers are blissfully unaware of the importance of transforming data into the proper HTML text. So, the data, as extracted from a database, could be in Unicode or ISO-8859-1, and the browser is configured to display UTF-8 - but worse than that, the data could contain a "&" character, which should be displayed as "&", or a double-quote which should be turned into """ in order to stop the HTML page from being corrupted.

In order to avoid this particular problem, php invented the concept of automatic quoting - Magic Strings - which are applied NOT ONLY to HTTP Post, HTTP Get and also in Cookie-generation, BUT ALSO there is an automatic quoting system that can be applied to Database data entry, as well, to deal with the equally bad situation where data entered into the Web browser - the View - could pass all of the Model "business logic" rules, but still contain valid SQL syntax, such as "terminate current SQL statement and begin a new one, please". Thus you get SQL injection attacks, and entire Web Servers are compromised.

The insanity of these piss-poor hacks - as a built-in feature of a major programming language that runs a significant chunk of the Web Services on the internet - should be abundantly clear.

Unfortunately, writing good code - writing a good framework - in php is simply not practical. The structure, look and feel of the language, and its heritage, is akin to that of Javascript. Both PHP and Javascript have the means to be "mixed in" to HTML, and that's not a good sign.

When you take away the means for foot-shooting, by not taking advantage of this "feature" of php (mixing), and you follow the much more sensible MVC-driven approach of separating out the programming code for the Model (php) from the View (HTML), then what you are left with is a programming language that looks extremely poor by comparison to the alternatives in which proper MVC-driven Web programming can be properly done.

So, if there is no choice but to use php, at the very least it is imperative that a framework is chosen that at least takes care of many of the mistakes that the novice programmer encounters. Given a choice, however, avoid php entirely.

Decent Frameworks

Web2py and The Django Project are both examples of extremely sophisticated MVC-led frameworks. Both of them take care of the usual tricks that trip up the novice programmer: both of them have SQL abstraction layers, through which SQL injection attacks are not possible; both of them take care to inform the developer that HTML is automatically escape-sequenced, and how to switch that off if desired; both of them take care in the conversion of data between different character sets.

Web2Py even has some integrated AJAX libraries that the developer can take advantage of, as does Django, to some extent.

Neither of the frameworks has the kind of functionality that the Unity framework offers - yet, Unity is a completely different beast from Web2Py and Django: it goes that little bit "further" in a way in which Web2Py, Django, and other python web frameworks cannot do, on their own, without the Pyjamas compiler Technology. Unity is under one thousand lines of code, and has more in common with flex or yacc and with automake than it does with a "Web Framework".

Unity could be adapted so that, alongside CherryPy, the Server-side output could be made Web-Server-Framework-agnostic, through the addition of extra stub code, and thus could be used to auto-generate Django Framework Server-side code, Web2Py server-side code and much more.

The tantalising possibility also exists for Web2py to integrate the features of the Unity Framework - to use the complete Pyjamas compiler. In this way, Web2Py's web Interface could automatically trigger the compilation of Python code into Javascript, for execution on the Web browser, instead of having hard-coded, hand-crafted and extremely limited AJAX libraries to rely on.

... and there's nothing to stop other frameworks from following web2py's lead... [web2py is unique amongst python web frameworks, in that the source code of the framework - and the developer's applications - can all be managed and edited through the web interface that is provided by the framework itself! Whilst many SCHEME development environments have had this kind of self-developing feature for decades, web2py is perhaps the first to bring it prominently to python and to the web]

Interesting related side-note

There are some startling implications of the Unity approach; the Pyjamas + web2py combination; the fact that the application can be programmed in a single language, and the fact that Web browsers look similar - enough to be made similar - to Desktop application frameworks.

First it's worth emphasising that the Pyjamas API is so similar to PyGtk2 and PyQt4 that a sister-project, Pyjamas-Desktop actually makes the Pyjamas API a Desktop-based Widget set. The underlying technology that makes this possible is Webkit, but an extensive search for comparable Gecko / XUL technology eventually turned up with Hulahop, which could also be used. The importance of mentioning Pyjamas-Desktop will be come clear, momentarily.

If web2py (or other suitable MVC-based framework) were to be enhanced so that sections of Python code could be marked or identified as "View" code, then those sections could be handed to Pyjamas, compiled, and executed client-side on the user's web browser. Alternatively, the same code could be executed server-side, as is presently done, and the application would feel no different - to the user.

Not only that, but the Model "business rules", written in Python, could both be compiled to Javascript, for execution on the user's browser, but also the same code could be executed server-side!

But the most interesting possibility of all is that of combining web2py with Pyjamas-Desktop. In this scenario, web2py farms out the client-side code, instead of into the Pyjamas Javascript compiler, directly into Pyjamas-Desktop. The glue logic between that code and the "Model" code would result in the code that ordinarily would be executed on the Web Server being executed by the user's desktop machine. Or result in an AJAX call to a Server, resulting in the same code being executed server-side, depending on either user preferences or on an application-dependent decision.

It's almost bewildering, idyllic, "Holy Grail" but very real, and almost there.

Conclusion

Old-school MVC-driven Web programming started off as being relatively easy, as long as a decent framework was used that helped the developer to avoid some of the inane gotchas, such as SQL statement escape-sequencing on data entry into the Model, and HTML entity transformation and character set compatibility on data display in the View.

However, as the limitations of the default "Controller" behaviour of Web browsers became quickly apparent, Javascript was introduced to overcome those limitations. The introduction of Javascript itself instantly complicated the picture, blurring the lines of responsibility for "View" creation and Model "business rules" enforcement. Languages and frameworks that have been designed with (or in some cases without) Old-school MVC approaches in mind are being left far behind. Some developers abandon HTML entirely and develop Java plugins, Flash and, more recently, Silverlight.

AJAX has improved user-responsiveness, but, overall, AJAX has just made the situation worse, not better, despite the promises and the possibilities, because the amount of Javascript that is used in the Web client to implement the "View" and the "Business rules" has increased but not fully taken over from the Web Server, and so the developer is forced to create multi-layered hybrids, where Views and Model "business rules" are fractured not only across multiple programming languages but also across multiple components: the worst-case nightmare for any developer wishing to stick to MVC principles.

Only by going the whole hog - fully into Javascript, augmented by Compiler Technology such as GWT and Pyjamas (and more specifically Unity) that allows both the Web Server and the Web Client to be programmed in exactly the same language - can the MVC approach be properly implemented and the user's expectations be satisfied, and thus both the developers' and the user's lives made easier. Gmail is the quintessential example of how this "whole-hog-Javascript" MVC approach can be achieved successfully.