Javascript Architecture/Application Structure Best Practices?

Question

Do these exist?

I've been a slave to big strongly typed OO languages (Java & C#) for many years and am a devotee of Martin Fowler and his ilk. Javascript, due to it's loosely typed and functional nature seems to not lend itself to the idioms I am used to.

What are the best practices for organizing a javascript rich client? I am interested in everything from where to keep your code, (one file or multiple files) to MVC patterns to gang of four patterns to layering.

Not putting stuff in the Global namespace seems to be the only consensus.

I am using JQuery as the "Extended API."

Solution 1

I like to use a sort of MVC client side architecture.

• I have a page CONTROLLER
• The DOM is my VIEW
• The server is my MODEL

Typically I create a singleton page controller class (with supporting classes off that is needed) that controls the ajax calls and view binding.

var pageXController = {
  init: function(param) {
    pageXController.wireEvents();
    // something else can go here
  },

  wireEvents : function() {
    // Wire up page events
  }

  // Reactive methods from page events
  // Callbacks, etc
  methodX : function() {}
}

$(document).ready( function() {
  // gather params from querystring, server injection, etc
  pageXController.init(someparams);
});

I should also add here that your MODEL in this case is your DTO's (Data Transfer Objects) which are optimised to the problem they solve. This is NOT your domain model.

Solution 2

For complex Javascript development, structuring your codebase it critical in my experience. Historically being a patching language, there is a great tendency that Javascript development ending up with massive script files.

I'd recommend to logically separate the functional areas of the application in to clear modules that are loosely coupled and self contained. For example as shown below your product suite might have multiple product modules and each module with multiple sub modules:

Once you have the ability to create hierachical modules, it is a mater of creating UI components in relavant sub-module. These UI components should also preferably be self contained. Meaning each with own template, css, localization, etc. like shown below:

I created a JS reference architecture with sample code to share my expierince I gained in couple of large scale JS projects. I'm the author of boilerplateJS. If you want a reference codebase where several of the critical concerns built-in, feel fee to use it as your startup codebase.

http://boilerplatejs.org

Solution 3

One thing you might want to look into is Backbone.js which gives you a nice framework for building Model classes to represent that data in your application and bind them to your HTML UI. This is preferred to tying your data to the DOM.

More generally, here is a great article on JavaScript best practices from the Opera development blog.

Solution 4

If we are talking about javascript apps architecture then Nicholas Zakas 2011 podcast is a must see: Nicholas Zakas: Scalable JavaScript Application Architecture

Also Addy Osmani's online reference: Patterns For Large-Scale JavaScript Application Architecture

View more solutions

Comments

[Yuriy Zubarev]

Nice attitude. Now you will be a slave to big dynamically typed semi-OO/functional languages. Sounds better, doesn't it?

[Jared Farrish]

Welcome to the jungle. Douglas Crawford is a good start for thinking about javascript: javascript.crockford.com

[prodigitalson]

It might be worth taking a look at the architecture of the Dojo codebase... Its one of the better implementations of highly architected client-side OO JS I've seen.

[Jared Farrish]

Also part of the Dojo Founding, TIBCO General Interface: developer.tibco.com/gi/default.jsp

[Paul Sasik]

You can actually continue your strongly-typed slavery and put together some nice web UIs with any of the following: Silverlight, JavaFX, ActiveX and of course, plain-old Java Applets

[pilau]

@PaulSasik Today you can use Typescript for strong-typed Javascript - although I wouldn't recommend it for the same reasons I wouldn't recommend Coffeescript.

[Guido Anselmi]

Thanks, that is the same first step I took. :) What I am wondering is if as the complexity grows if there are standard means of managing that complexity?

[Slappy]

I think so long as you follow a standard pattern like this, maintainability works. If your page has a LOT of functionality you could also create several "controller" singletons representing functionality/domain boundries (I use the word controller loosely) and aggregate them on a top level controller.

[Slappy]

I would avoid additional libraries for something that can be solved with a pattern. You add extra weight and requests to do simple house cleaning tasks.

[Guido Anselmi]

Cool. Thanks Slappy, that is in fact the course I am following. It us very reassuring to hear that it is not loony tunes.

[Guido Anselmi]

Done. I guess this is all there is.