Question

Just to keep things interesting and close my final open question, the solution that implements the below functionality in a nicely organized manner with a decent architecture gets a good bounty. The full code is on jsfiddle, and feel free to ask any questions 🙂

How do you usually organize complex web applications that are extremely rich on the client side. I have created a contrived example to indicate the kind of mess it’s easy to get into if things are not managed well for big apps. Feel free to modify/extend this example as you wish – http://jsfiddle.net/NHyLC/1/

The example basically mirrors part of the comment posting on SO, and follows the following rules:

1. Must have 15 characters minimum,
   after multiple spaces are trimmed
   out to one.
2. If Add Comment is clicked, but the
   size is less than 15 after removing
   multiple spaces, then show a popup
   with the error.
3. Indicate amount of characters remaining and
   summarize with color coding. Gray indicates a
   small comment, brown indicates a
   medium comment, orange a large
   comment, and red a comment overflow.
4. One comment can only be submitted
   every 15 seconds. If comment is
   submitted too soon, show a popup
   with appropriate error message.

A couple of issues I noticed with this example.

• This should ideally be a widget or some sort of packaged functionality.
• Things like a comment per 15 seconds, and minimum 15 character comment belong to some application wide policies rather than being embedded inside each widget.
• Too many hard-coded values.
• No code organization. Model, Views, Controllers are all bundled together. Not that MVC is the only approach for organizing rich client side web applications, but there is none in this example.

How would you go about cleaning this up? Applying a little MVC/MVP along the way?

Here’s some of the relevant functions, but it will make more sense if you saw the entire code on jsfiddle:

/**
 * Handle comment change.
 * Update character count. 
 * Indicate progress
 */
function handleCommentUpdate(comment) {
    var status = $('.comment-status');

    status.text(getStatusText(comment));
    status.removeClass('mild spicy hot sizzling');
    status.addClass(getStatusClass(comment));
}

/**
 * Is the comment valid for submission
 * But first, check if it's all good.
 */
function commentSubmittable(comment) {
    var notTooSoon = !isTooSoon();
    var notEmpty = !isEmpty(comment);
    var hasEnoughCharacters = !isTooShort(comment);

    return notTooSoon && notEmpty && hasEnoughCharacters;
}

/**
 * Submit comment.
 * But first, check if it's all good!
 */
$('.add-comment').click(function() {
    var comment = $('.comment-box').val();

    // submit comment, fake ajax call
    if(commentSubmittable(comment)) {
        .. 
    }

    // show a popup if comment is mostly spaces
    if(isTooShort(comment)) {
        if(comment.length < 15) {
            // blink status message
        }
        else {
           popup("Comment must be at least 15 characters in length.");
        }
    }
    // show a popup is comment submitted too soon
    else if(isTooSoon()) {
        popup("Only 1 comment allowed per 15 seconds.");
    }

});

Edit 1:

@matpol Thanks for the suggestion for a wrapper object and plugin. That will really be a big improvement over the existing mess. However, the plugin is not independent and as I mentioned, it would be part of a larger complex application. Application wide policies on client/server side would dictate things like minimum/maximum length of a comment, how often can a user comment, etc. Surely the plugin can be fed this information as parameters.

Also, for a rich client side application, the data would have to be separated from its html representation, as many server round-trips can be saved since the application is data-aware and things could be stored locally, and periodically updated on the server, or upon interesting events within the application itself (such as when the window is closed). Here’s why I don’t really like a plugin approach. It would work as in provide a packaged representation, but it would still be centered around the DOM, which is going to be problematic when you have 20 such plugins in the application, which is not an absurd number by any means.

Answer 1

The way in which I would do this is 3 fold.

1. Encapsulate javascript in small well-defined classes within namespaces
2. Javascript classes should have HTML they require “injected” into them as dependency allowing out-of-browser unit testing
3. Move as much client-side functionality to server as possible and use a concept known as AHAH

Javascript name-spacing

This can be achieved easily and has been covered in other posts such as this Is there a "concise" way to do namespacing in JavaScript?

Small encapsulated classes

Javascript code, just like server-side code should be well encapsulated with small cohesive classes and methods. Each class lives in a separate file, named along with the namespace it is in, eg: MyCompany.SomePackage.MyClass.js.
Excessive HTTP requests to each file can be saved via combining and minifying these class files at build time.

Dependency Inversion in Javascript

So effectively instead of selecting the elements you require to work with inside your class, like this:

var MyNamespace.MyClass = function() {
  var elementINeed = $('#IdOfElementINeed');
}

You would inject it as such:

var foo = new MyNamspace.MyClass($('#IdOfElementINeed'));

var MyNamespace.MyClass = function(incomingDependency) {
  var elementINeed = incomingDependency;
}

This technique lends itself well to testable javscript and seperation of concerns through MVC style layering of your code.

AHAH and Client-side simplification

AHAH is quite an old technique that has been around for quite some time in web-development, although is making a resurgence amongst web aficionados for its pure simplicity. However, the philosophy must be bought into at more than the architectural technique level and it must be used as a replacement for all your client side javascript eg: validation, showing/hiding dynamic content, calculations etc

Where you may used to have attached an onClick event with client-side complexity:

$('#someElement').click(function(){
  // insert complex client-side functionality here, such as validating input
  // eg var isValid = $(this).val() < minimumCommentLength;
  // update page based on result of javascript code
  // eg $('#commentTooLong').show();
})

Now you would simply trigger an ajax request back to the server to get the new HTML and simply replace all or some of the elements you are interested in as such:

$('#addCommentButton').click(function(){
  $.ajax({ 
    url: "/comment/add", 
    context: document.body, success: 
    function(responseHTML){
        $('body').html(reponseHTML);
      }});
})

Obviously this is a trivial example, but when used effectively, ANY javascript event on the page, simply fires off the identical ajax request and HTML replacement, greatly reducing the amount of client-side code required. Moving it to the server where it can be effectively tested.

AHAH nay-sayers, will argue that this is not a performant way to run a web-site, however I have used and seen this technique on sites with 56k modem access and also massively scaled public web-sites. The result is of course slower, but you can still produce sub 100 millisecond round trips, which is practically instant to humans.