Why jQuery needs JavaScriptMVC

Monday 09 August, 2010 by moschel

More than a year and a half ago, I begged the jQuery community to start taking seriously the challenges of large scale JavaScript development on the jQuery forum.  The response - jQuery handles most of the challenges. I disagree! But today, Rebecca Murphey, someone infinitely better at communicating than myself, echoed the call. I suspect it will create all kinds of commotion. So, I will try again to outline why jQuery needs a project like JavaScriptMVC and hope that attitudes have changed.

NOTE: If you're wondering why jQuery should even care about enterprise development read why .

NOTE: If you need a much more succinct (and probably clearer) explanation of why JavaScriptMVC is important for jQuery developers read it here.

NOTE: I am not arguing that jQuery should become JavaScriptMVC.  I'm arguing that there are things jQuery doesn't do. This is good for the library, but a challenge for the community. JavaScriptMVC makes these things very simple.

There are TONS of reasons to use JavaScriptMVC and I'm busy using these reasons to build kick ass apps for our clients. So, I'll try to quickly highlight a few of them from the perspective of someone writing a JavaScript application with just jQuery / jQueryUI / and qUnit and include a little bit about why the jQuery project leadership should care.

Organization

JavaScriptMVC is all about organizing your code. It does this in a variety of ways.

Standard Folder Structure

JavaScriptMVC provides a standard way of organizing everything in a JavaScript app. An example folder structure for "Acme" company's "Callcenter" application might look like:

Folder

Reusable widgets/plugins are in the "acme" folder. These can be easily shared and updated across multiple projects with JavaScriptMVC's gem-like package system. The callcenter application's files are in the callcenter folder. Callcenter's functionality is separated into the controllers, models, and views folders.

If you look closely, you'll notice JavaScriptMVC also organizes a project's tests, documentation, and build scripts. This application folder structure, and stubbed tests, are easily created with JavaScriptMVC's packagedgenerators .

Why should jQuery care?

jQuery development is can be an ad-hoc mess of scattered plugins and files. JavaScriptMVC forces you to clean the mess and put everything where it belongs. If you are looking for code, you'll know where to find it. The code generators and packaging system make it easy to get started.

Dependency Management

JavaScriptMVC makes it easy to load scripts that load other scripts that load other scripts; you know, dependency management. It's as simple as doing:

steal.plugins(
  'acme/datatable',
  'acme/modal').then(function($){
  
  //code that depends on datatable and modal
})

*** steal only loads a dependency once ***

Why should jQuery care?

The lack of a dependency management hurts us like IE's peek-a-boo bug - in not obvious, but critical ways:

  • Organization - Lots of functionality gets crammed into a single file, concerns are not isolated.
  • Bloated apps -  Plugin authors are less likely to include other scripts as dependencies, so multiple plugins end up doing similar things.

We need more plugins like jQuery UI's positionable. But without a dependency management system, plugin authors will have no reason to separate positionable from their context menu plugin.

Steal does dependency management, but it also does compression auto-magically (without having to write a separate build script). It can even generate the source code to remove steal as a dependency.

Model - View - Controller

Having strong layers in an application design is bedrock for constructing a maintainable application. JavaScriptMVC provides three best-in-class layers:

  • Ajax / Domain Model - Model
  • Client Side Templates - View
  • Events / Plugin - Controller

Model

JavaScriptMVC's model encapsulates Ajax requests and wraps service data. Manipulating and wrapping a REST services is as easy as:

$.Model.JsonRest.extend( "Recipe", {
  //a helper function
  isTasty: function(){
    return !/mushroom/.test(this.description)
  }
});

Making a request looks like:

Recipe.findAll( {}, function( recipes ){
  
  if( recipes[0].isTasty() ){
    alert( 'the first recipe is tasty' )
  }
})

There are extensions to model that add functionality like associations, validations, ACLs, and storage.

Why should jQuery care?

Many jQuery plugins make AJAX requests. Often, you are limited in configuring how the plugin makes its AJAX request or how it consumes the reponse. 

The result is that you have to change the service to make it work with the widget you are using. There's something very wrong about this! A Model layer provides a useful abstraction for widgets. They can manipulate a model interface without having to support a wide variety of services.

Controller

Controller is a crazy powerful jQuery plugin factory. It's much stronger than jQueryUI's widget. Find out why you and jQuery should care here.

View

JavaScriptMVC's view makes using any client-side template language practical. By practical, we mean you can put templates into separate files and compress them into a production build. The following renders an EJS template with data:

$("#foo").html('//path/to/template.ejs', data);

To add a template to the production build:

steal.views( "//path/to/template.ejs" );

*** convert the template to a function, eliminating the processing step, and the template engine source ***

Why should jQuery care?

There's been a lot of hubbub about jQuery-tmpl. What shocked me is that no one seems to consider what is necessary to actually use script tags in a large application. Putting them in a script tag! Don't make me laugh. See how reusing templates between pages goes.

Instead of trying to make a 'standard' template langauge (which no one will ever agree on), jQuery could look to standardize how templates are used. JavaScriptMVC provides this by making it possible to use, organize, and build your project with any template system. View currently supports EJS, JAML, and Micro templates. Adding other templating languages is easy.

Testing

FuncUnit is super awesome and superior to qUnit in every way (it extends qUnit). Coupled with JavaScriptMVC, it provides a way to organize and run all your tests automatically.  Watching FuncUnit regression test all our widgets before functional testing our application in every supported browser gives me chills. Find out more about FuncUnit here.

Why should jQuery care?

Duh, solid testing is 100% critical on enterprise apps.

Documentation

JavaScriptMVC documentation engine, DocumentJS, is really powerful. It's able to document any complex JS structure, show code, etc.  In fact, it creates the entire JavaScriptMVC website.

Why should jQuery care?

The jQuery wiki isn't a private documentation engine. jQuery should provide a solution for easily documenting your app.

Quality Low Level Plugins

JavaScriptMVC has a bunch of quality low level jQuery plugins:

  • Closest - allows open child selectors with event delegation
  • Compare - compare document position
  • Cookie - a quality cookie plugin
  • CurStyles - get multiple styles fast
  • Dimensions - set and animate inner/outer height and width
  • Fixture - Ajax Fixtures
  • FormParams - Converts forms to objects

special events

  • Default - scalable default events
  • Destroyed - listen to when an element is removed
  • Drag / Drop - delegatable drag drop
  • Hashchange - hashchange events
  • Hover - delegatable hover events
  • Offline - offline events
  • Resize - normalized resize events

and language helpers

  • toJSON
  • rSplit - a cross browser regexp split function
  • Vector - for complex scalar math
  • String - string helpers

Why should jQuery care?

Having a solid set of low-level plugins makes building higher-order functionality much easier. Packaging these into a jQuery Enterprise solution only removes more of the guesswork trying to find the right tool.

Everything Stands Alone

With the new release of JavaScriptMVC, we've taken great pains to minimize dependencies. Every part of JavaScriptMVC, from Controller, to the compression engine, to FuncUnit can work independently of everything else.

Why should jQuery care?

If jQuery targets enterprise development, it should do that without losing what makes jQuery great - providing an excellent API to solve a specific problem. Frameworks can easily become an enormous ad-hoc collection of decent, but not best in class, tools. This can make the overall experience less attractive. But, by keeping everything isolated, we are able to swap out large parts of JavaScriptMVC with better techniques and tools.

Conclusion

JavaScriptMVC is currently the best way to do enterprise jQuery.  It provides everything you need to build the next GMail. But, it doesn't have the support of the jQuery community and leadership. I understand this. jQuery isn't exactly for serious JavaScript development. This is probably why I find myself sometimes 'fitting in' better with Dojo guys - they are building the types of apps I want to build.

If jQuery is going to progress, it needs to start meeting the needs of enterprise developers AND designer-ish developers. Here's how I would do that:

  1. Start an enterprise jQuery project.
  2. Solve the dependency-management and build problem. I think some combination of RequireJS and Steal would work very well.
  3. Adopt JavaScriptMVC's folder structure (minus the MVC folders, but including how tests, docs, and scripts are organized). It's scalable, easy, and practical.
  4. Figure out namespaces and how to make extending functionality really easy.
  5. Adopt something like JavaScriptMVC's View. It solves the client-side template problem.
  6. Adopt FuncUnit. It solves client-side testing.
  7. Standardize on a 'widget' factory that actually has something to offer (like how controller auto-binds and unbinds event handlers and is extendable).
  8. Start adding in 'best-of-class' low-level, non-ui plugins.

I hope jQuery starts taking enterprise seriously. JavaScriptMVC is a perfect candidate for jQuery to leapfrog years of development and trial and error. My great fear is that jQuery will have something like 90% of JavaScriptMVC, but it will have it 3 years from now. I think we'll end up waiting until someone on jQuery core is asked to develop a 100k lines-of-code project.

In the mean time, I'll let Rebecca be the champion of Enterprise jQuery development.

Subscribe to:

Related Content

Copyright ©2007-2010 Jupiter IT.