Of all the standards that a front-end team might want to implement, those that concern the identification and graceful degradation of cross-browser feature sets can be the hardest to define.

With that in mind, I’ve been poking around the front-end community looking for possible solutions. By far the most common approach—and one that gains an astounding level of attention in the community—is to implement Modernizr, a JavaScript feature sniffer created by Faruk Ate?, Paul Irish and Alex Sexton.

Unfortunately, despite my respect for the developers involved, I just can’t advocate Modernizr as a solution. Let me explain why; but first, let’s revisit some concepts that are going to be quite relevant…

The web standards trifle

The separation of structure, presentation, and dynamic behaviour is imperative to web standards. To that end, Andy “Malarkey” Clarke wrote a fantastic post detailing a method he liked to use to explain this fact to clients. He entitled it “the web standards trifle”.

In Andy’s metaphor, the separation of concerns can be imagined as follows:

1. Sponge

   This layer is your content, marked-up with well structured and valid semantic HTML. This HTML provides more information about each piece of content and allows any device reading the code to output as appropriate.

2. Fruity jelly

   This is your presentational layer. This separates all your presentational code into CSS, potentially allowing a user to override it with their own, or for you to serve something different based on context, e.g. a print or mobile stylesheet.

3. Custard

   This is the layer that accommodates any on-page behaviours. In the world of web standards we use this layer to progressively enhance our HTML and CSS layers with more interactive magic. I’ll come back to this later.

The true virtue of this divide is that the presentational (jelly) and behavioural (custard) layers can potentially be removed or overridden without affecting each other, or the content and markup beneath. This is hugely important if we want our websites to maintain client agnosticism and improve accessibility.

Progressive enhancement

Following the publication of this article there have been several suggestions that I explain the difference between graceful degradation and progressive enhancement. Suffice to say, this is something I have covered previously in another article.

Browser vs. Feature Sniffing

Browser “sniffing” is the act of attempting to discern a user’s browser by some means. This “awareness” can then be used in conditional code to control output or interaction for a specific browser. This technique was used a great deal in days of yore, when browsers had very different rendering engines and didn’t all conform to web standards. However, it was only ever really required in JavaScript.

The old school way:

if (document.all) {
    // IE4
    height = document.body.offsetHeight;
} else if (document.layers) {
    // NN4
    height = window.innerHeight;
} else {
    // other
    height = 0;
}

Not a good solution

There are problems with the method used above; for one thing, it is not the most direct method of identifying a browser. However, putting that aside for the moment, there are issues even with the theory of browser sniffing:

It’s quite obvious that browser sniffing does not scale. As new browsers are released, the sniffing code will need updating.

To make matters worse, many manufacturers developed their browsers to identify themselves incorrectly to get around legacy browser sniffing code. This ultimately meant that sometimes browsers were misidentified.

Ultimately browser sniffing is not a good solution. If you adopt it, you will usually end up maintaining separate streams of development whenever you need to add or update features. There are ways to mitigate that pain, but what if there was a better solution?

Feature sniffing

A more scalable approach is to use object detection in JavaScript to discover if a feature is available before you use it. An example of this might be:

if (document.querySelector) {
    element = document.querySelector(selectors);
}

The obvious advantage here is that it is browser agnostic; there are no assumptions as to which browser is involved at all. Using this technique, we overcome the scalability and maintenance headaches incurred through browser sniffing, and we can develop for graceful degradation from the outset.

CSS is a DSL that lacks features

Now, that’s all very well and good when we’re talking about JavaScript, but what happens when we need to affect the presentation layer?

CSS is a very simple domain specific language (DSL) that functions as a series of rules that override each other in a variety of ways (the cascade). There is no mechanism to detect a specific feature or a user-agent; only media types and potentially the odd CSS hack where a user-agent has imperfectly implemented an interpreter. There are also no conditionals; you just have to use the cascade to provide alternatives based on specificity or even just source order.

With these limitations, it is impossible to implement either browser or feature sniffing in CSS. This means we need to find an alternative method to affect the cascade based on the user’s feature set.

The Modernizr method

Step in Modernizr. In the words of the documentation:

Modernizr aims to bring an end to the UA sniffing practice. Using feature detection is a much more reliable mechanic to establish what you can and cannot do in the current browser, and Modernizr makes it convenient for you in a variety of ways:

1. It tests for over 20 next-generation features, all in a matter of milliseconds.

2. It creates a JavaScript object (named Modernizr) that contains the results of these tests as boolean properties.

3. It adds classes to the html element that explain precisely what features are and are not natively supported.

Following along so far? For the most part, that all seems fairly good. What’s more, Modernizr is definitely being pushed as the solution of choice amongst the front-end community:

• Mark Pilgrim’s Dive into HTML5 “Detection” chapter
• Faruk’s “Taking Advantage of HTML5 and CSS3 with Modernizr” on A List Apart
• Web Designer Notebook: How to use Modernizr
• Image Gallery tutorial on Sitepoint

So with all that in mind, let’s go back to why I will not be recommending Modernizr as a best practice:

Sniffing CSS features with JavaScript

The real issue is that Modernizr uses JavaScript to do the feature sniffing. This method is absolutely fine if we were only looking to test for the features in JavaScript. However, Modernizr is marketed on its ability to detect CSS3 and HTML5 features so that you can write gracefully degrading CSS:

Modernizr is a small and simple JavaScript library that helps you take advantage of emerging web technologies (CSS3, HTML 5) while still maintaining a fine level of control over older browsers that may not yet support these new technologies.

If Modernizr had sold itself as a JavaScript feature sniffing solution that also detected CSS features perhaps I could be more forgiving. In that context, it would be the developers’ responsibility to use Modernizr correctly. However, since the Modernizr site and documentation are selling it specifically as a CSS feature sniffing solution, for primary use within CSS, the error is clearly with the Modernizr team themselves.

It’s all down to the final step outlined in the documentation I quoted earlier:

It adds classes to the html element that explain precisely what features are and are not natively supported.

Modernizr uses JavaScript to add those classes to the html element; one for each of the features detected in the current browser. If we examine the generated source we see the following:

<html lang="en" dir="ltr" id="modernizr-com" class=" js flexbox canvas
canvastext webgl no-touch geolocation postmessage websqldatabase indexeddb
hashchange history draganddrop websockets rgba hsla multiplebgs backgroundsize
borderimage borderradius boxshadow textshadow opacity cssanimations csscolumns
cssgradients cssreflections csstransforms csstransforms3d csstransitions
fontface video audio localstorage sessionstorage webworkers applicationcache
svg inlinesvg smil svgclippaths">

When I first saw that, I was horrified. Not only is it ridiculously cluttered, it also feels decidedly unsemantic and looks like a terminal case of classitis. However, let’s try to be pragmatic here; it’s a means to an end, potentially a minor side-effect to a process that will win us some power in the bigger picture. In fact, it’s one step on from Paul Irish’s proposed work around to the FOUC (flash of unstyled content) which I’ve advocated as a reasonable fallback to marking progressively enhanced objects with an “enhanced” class.

Making use of the classes

The Modernizr method allows you to assign styles based on these new classes on the document’s root element like so (example lifted from the Modernizr docs):

button.glossy {
   background: #ccc url(gloss.png) 50% 50% repeat-x;
}
.cssgradients button.glossy {
   background: #ccc -webkit-gradient(linear, left top, left bottom,
         from(rgba(255,255,255, .4)),
         color-stop(0.5, rgba(255,255,255, .7)),
         color-stop(0.5, rgba(0,0,0, .2)),
         to(rgba(0,0,0, .1)));
}
.cssgradients button.glossy:hover {
   background-color: #fff;
}

Here we can see that button.glossy is first defined with a standard png as its background. The Modernizr-added .cssgradients class is then used to increase specificity and assign a WebKit gradient instead.

What happens if we approach the problem without the .cssgradients class:

CSS allows us to define a property twice in the same rule. It also contains built-in error handling that will ignore a property it doesn’t understand; so browsers that do not understand -webkit-gradient(), for example, will simply ignore a property that uses it. This allows us to progressively enhance our CSS like so:

button.glossy {
   background: #ccc url(gloss.png) 50% 50% repeat-x;
   background: #ccc -webkit-gradient(linear, left top, left bottom,
         from(rgba(255,255,255, .4)),
         color-stop(0.5, rgba(255,255,255, .7)),
         color-stop(0.5, rgba(0,0,0, .2)),
         to(rgba(0,0,0, .1)));
}
button.glossy:hover {
   background-color: #fff;
}

However, because we can no longer target the .cssgradients class specifically, we cannot target the button:hover styles only when CSS gradients are detected. Clearly this is an issue we’ll have to find some way around and is exactly what Modernizr is attempting to solve.

This all seems as if Modernizr is giving us a great deal of power, however, it comes with a significant cost.

Dependency on JavaScript is bad

Fellow web developer and good friend Mike Davies wrote a really great article containing a good summary of obstacles potentially preventing JavaScript from executing back in October 2010. This followed a somewhat presumptuous post by Nicholas Zakas on the YDN regarding the number of users with JavaScript disabled.

In short, there are a large number of obstacles that can affect the execution—or even rewrite the source of—JavaScript included in your pages. Hence, dependancy on JavaScript is bad because it introduces many significant points of failure.

As an example of why dependency on JavaScript can be catastrophic, I recommend you read another of Mike’s posts on Gawker’s JavaScript dependent URIs and how it broke their sites quite considerably. It’s worth noting that the Gawker sites have since seen the error of their ways and are attempting to fix the damage.

Styling dependant on JavaScript

By adding styles that are specific to classes that have been inserted with JavaScript, we are making those styles dependant on JavaScript. This means those styles will fail to apply if JavaScript itself has been disabled or, more commonly, the JavaScript file applying the classes has failed to load or execute successfully due to one of the reasons above. In essence, we may just as well add those styles with JavaScript directly because we’ve already broken the web standards separation of concerns.

Do we really want to remove the majority of CSS items covered by Modernizr if the Modernizr JavaScript include fails for some reason?

It would only be the feature-sniff-dependant CSS rules that would fail, since those classes would now be missing. Potentially this only means the loss of a few nice in-browser rendering optimisations. However, it also means there is a significant loss in the overall structure of specificity within your stylesheets, which could easily cascade unintended effects through to other elements. This could easily result in some content being styled to be unreadable, or worse, incorrectly hidden. This would be very bad indeed.

Alternative solutions

Modernizr is clearly unfit for purpose. If it were simply a JavaScript feature sniffing library for use only in JavaScript, it would be a suitable solution although only really useful for JavaScript progressive enhancement.

With that in mind, what other options are available that allow us to target our CSS?

Server-side browser sniffing

We could browser sniff on the server and add a class to the html element as we generate the HTML that is delivered in the HTTP response. This could result in something like the following:

<html lang="en" dir="ltr" class="firefox">

This means we can target CSS with the .firefox class in much the same way that we used the feature classes that Modernizr provided. There is no way for us to perform feature sniffing on the server; the best we could offer is a feature lookup based on the user-agent string that we’ve used to sniff the browser, but that would ultimately still be browser sniffing.

In fact, the best browser sniffing solution would allow us a little more flexibility on browser versions:

<html lang="en" dir="ltr" class="moz ff ff3-6">

Note I’ve added several classes this time; one for the rendering engine, one for the browser, and one that contains the major and minor versions. This would allow us more specificity.

Update: Matthew Pennell has written an interesting post on server-side browser sniffing with .htaccess and environment variables. Definitely worth a read.

Cache issues

However, server-side browser sniffing means that you’ll run into issues if your pages are publicly cacheable. This server-side solution results in a different HTTP response (the HTML) for each differing browser.

If you utilise any intermediary caching (Squid, Varnish, or a custom origin CDN) for static pages, and you use server-side browser detection, you need to make sure those caches don’t inadvertently send the wrong content to the wrong browser. To do this you’ll need to Vary: User-Agent header in the HTTP response. This instructs any intermediary caches to store multiple copies of the page (one for each User-Agent string that it sees) and to inspect the incoming User-Agent string when looking for cached responses to the current request.

IE targeting with conditional comments

If we’re entirely honest with ourselves as web developers, we can probably admit that the majority of woes we experience in CSS are as a direct result of features that any given version of Internet Explorer has not implemented. In fact, I regularly interview developers who advocate maintaining a separate stylesheet for IE that is included through the use of IE’s conditional comments. Having attempted to use this method in the past, I can confidently say that it is a maintenance nightmare and quickly becomes pretty unmanageable.

A better technique would be to adopt conditional comments to add IE specific classes in much the same way we have with Modernizr or server-side browser sniffing. This method was first proposed by none other than Paul Irish back in 2008 in his article “Conditional stylesheets vs. CSS hacks? Answer: neither“. With that method, our html element would look like this:

<!--[if IE ]>
<html lang="en" dir="ltr" class="ie">
<![endif]-->
<!--[if !IE]>-->
<html lang="en" dir="ltr">
<!--<![endif]-->

This looks a bit odd, and often (for the true markup perfectionist) takes a bit of getting used to. However, it does give us what we need without requiring JavaScript or multiple cache versions.

We can even make it more specific if we so desire:

<!--[if lt IE 7 ]>
<html lang="en" dir="ltr" class="ie ie6">
<![endif]-->
<!--[if IE 7 ]>
<html lang="en" dir="ltr" class="ie ie7">
<![endif]-->
<!--[if IE 8 ]>
<html lang="en" dir="ltr" class="ie ie8">
<![endif]-->
<!--[if IE 9 ]>
<html lang="en" dir="ltr" class="ie ie9">
<![endif]-->
<!--[if gt IE 9]>
<html lang="en" dir="ltr" class="ie">
<![endif]-->
<!--[if !IE]><!-->
<html lang="en" dir="ltr">
<!--<![endif]-->

Quite clearly this gets ever uglier, but the solution is entirely encompassed in the structural layer; we will always have the correct class, even if CSS or JavaScript are unavailable for some reason. We also have the same markup regardless of user-agent string, which means caching is not a problem.

The only flaw with this solution is that we can only target versions of Internet Explorer. No other browser implements conditional comments.

Use CSS properly and make use of the cascade

As previously stated, CSS is designed to cascade. This means the built-in error handling will ignore properties the interpreter does not understand, and we can override rules based on specificity and source order. In most cases, these key features are more than adequate to develop gracefully degrading stylesheets.

Most capable front end developers are already doing this and coping just fine. Add this to the previous IE targeting approach and you’ll find that you do not need to over-engineer a solution.

In summary

So, in summary then, I absolutely cannot recommend implementing Modernizr as a best practice for front end development. It attempts to solve a problem from the wrong direction, and introduces a new potential point of failure. What’s more it breaks the fundamental ethic of web standards; the separation of concerns.

I continue to recommend well crafted, gracefully degrading CSS, backed up by conditional commented classes on the html element for targeting IE.

Modernizr may still be a worthy solution for JavaScript-only feature sniffing, if only it allowed the developer to disable the injection of classes on the html element.

Without further a-do, let’s jump in with the technical stuff:

A quick note on variable declaration

The var declaration allows you to chain definitions in a comma separated list; what’s more that list can reference variables declared earlier in the same list.

Take this code as an example:

var el = document.getElementById(“my-element”);
var elWidth = el.offsetWidth;
var elHeight = el.offsetHeight;
var elArea = elWidth * elHeight;

This could alternatively be written like so:

var el = document.getElementById(“my-element”),
    elWidth = el.offsetWidth,
    elHeight = el.offsetHeight,
    elArea = elWidth * elHeight;

Personally, I prefer the latter method simply because it keeps my var declarations in one place (where possible) without endless repetition of the var keyword. However, this is simply a minor note on coding style, rather than something that can improve the operation of your code.

Understanding object-oriented scope

As any experienced JavaScript coder knows, JavaScript is functionally scoped; this means any variables created within an object or function are only available within that object or function.

Simple, right?

Well no, there are actually a couple of complications to this behaviour that you should really understand:

Passing by reference

When passing arguments in JavaScript, it’s not immediately clear how those arguments are being handled internally. In fact, it is entirely dependant on the data-type of those arguments.

When passing arguments of type Number, String, or Boolean, JavaScript will pass them in by value. This means that the value stored in the argument will actually be a copy of the original value:

function accidentalFall(count) {
    count = count - 1; // Remove one
}

var greenBottles = 10;

alert(greenBottles); // greenBottles is 10

accidentalFall(greenBottles); // Pass by value

alert(greenBottles); // greenBottles still 10

Passing in an object, however, passes the argument by reference. This means that, within the function, the argument is not a copy, but a reference—or link, if you like—to the original object. This means any members of that object are available within our function, and any changes to the object passed as an argument will be reflected outside of the scope of the function.

Actually, the way JavaScript handles references is another blog article in itself. Watch this space.

Here’s our example again:

function accidentalFall(obj) {
    obj.count = obj.count - 1; // Remove one
}

var greenBottles = {
    count: 10
};

alert(greenBottles.count); // 10

accidentalFall(greenBottles); // Pass by reference

alert(greenBottles.count); // 9

This is a subtle difference, but one, I think you’ll agree, that is important to understand.

The this special operator

The this operator can be used to obtain a reference to the current context object and allows properties and methods within that execution context to be referenced. The context object can be considered a “hidden” parameter that is passed to any function.

There are four ways the context is made available to a function:

Implicitly with a method

var myObject.method = function(arg1, arg2…) {
    // Context here is myObject, and has been passed
    // implicitly.
}

Implicitly with new

var myConstructor = function(arg1, arg2…) {
    // Here we have a new anonymous context
    // understandable as the instance…
}
// …so the context here will be myObj
var myObj = new myConstructor(arg1, arg2…);

Explicitly with Function.call

var myObject.method = function(arg1, arg2…) {
    // Implicit context is myObject
}
// Explicitly force context to anotherObject
myObject.method.call(anotherObject, arg1, arg2…);

Explicitly with Function.apply

var myObject.method = function(arg1, arg2…) {
    // Implicit context is myObject
}
// Explicitly force context to anotherObject
myObject.method.apply(anotherObject, [arg1, arg2…]);

In general, JavaScript developers tend to rely on implicit context passing rather than explicit. However, there is one situation where this reliance falls down…

A common problem

When registering event handlers against DOM nodes in JavaScript, the this context no longer references the method’s parent object, but rather the DOM node to which the event handler is registered.

The easiest way around this is to make sure the reference to the context object originally stored in this is maintained before defining the event handler:

var widget.init = function () {
    var myButton = document.getElementById(“my-button”),
        counter = 0,
        that = this;

    myButton.onClick = function(event) {
        that.counter++;
        this.innerHTML = “Clicked!”;
    }
}

Further to this, according to Douglas Crockford, there is an error in the ECMAScript spec. that causes this to be set incorrectly for inner functions; something that he discusses in his article Private Members in JavaScript:

function Container(param) {
    function dec() {
        if (secret > 0) {
            secret -= 1;
            return true;
        } else {
            return false;
        }
    }

    this.member = param;
    var secret = 3;
    var that = this;

    this.service = function () {
        if (dec()) {
            return that.member;
        } else {
            return null;
        }
    };
}

Now, the “var that = this” technique is certainly a bone of contention amongst members of the JavaScript community, but I’m firmly on the fence in the whole discussion. Certainly my second example could be solved with a complex network of Function.call and Function.apply instead of that.member, but my first example would be somewhat more difficult.

Personally, I feel if Doug Crockford—a developer with many years more experience and infinitely more JS knowledge than myself—says it’s ok, then I’m fine with it.

Garbage collection

As JavaScript is a scripting language, it implicitly allocates memory for objects, strings, variables, and so on as it runs. Garbage collection is the process by which the JavaScript engine detects when those pieces of memory are no longer reachable—that is, they could not possibly ever be used again—and reclaims the memory.

The ECMAScript specification (of which JavaScript is an implementation) doesn’t include a definition on how a JS engine should handle garbage collection, so although each JavaScript engine includes garbage collection—memory usage would quickly snowball if they didn’t—they all handle it somewhat differently.

Some engines are better than others; Google’s V8 is exceptionally good, where as the IE JScript engine is notoriously bad (often resulting in memory leaks).

Nested functions and closures

JavaScript allows the nesting of functions, creating nested scope blocks that inherit scope from their parents all the way up to the global scope.

Take this code for example (there are much better ways of doing this; this method is only in the interests of illustration):

function appendList(list, itemPrefix) {
    var getListItem = function(x) {
        return document.getElementById(itemPrefix + x);
    }

    for (var i = 0, j = list.length; i < j; i++) {
        getListItem(i).innerHtml += ‘ [done]’;
    }
}

In the above example getListItem is a nested function within appendList. This means it inherits everything within the scope of appendList. As a result of this, the inner function is able to make use of the itemPrefix parameter that is passed to its parent without it needing to be passed in as another parameter on getListItem.

When JS automatically garbage collects the appendList function, it will find no external references to the getListItem function and will garbage collect that as well.

This is a useful feature of JavaScript, and allows for fairly advanced lambda functions (anonymous functions), as well as providing a useful tool for namespacing library functions.

However, if, upon garbage collection, JavaScript finds an external reference to a nested function, it creates a closure of scope; thus maintaining access to all the variables required within the scope of that function.

This is known as a closure.

Common usage of closures

The most common occurrence of a closure in JavaScript is when declaring event callbacks. This is simply due to the fact that the callback function is referenced within the event listener once registered.

However, it’s important to understand that many modern libraries, plugin architectures, and plugins themselves also make use of closures, and understanding how they use them can mean the difference between controlled and uncontrolled memory usage.

Invisible pitfalls are invisible

It’s obvious when you think about it, but all closures have a potentially high memory imprint as they are maintaining much more than just their constituent parts. What’s more, because of their inherent avoidance of garbage collection, they are maintained until they are manually destroyed either by the code, or by a page refresh.

Prototypal inheritance

I did discuss prototypal inheritance in my original Object-Oriented Javascript article, however I just want to go into a little more detail here.

In a prototypal system, objects are supposed to inherit from objects; unlike in a classical inheritance system where classes inherit from classes and instantiate objects. JavaScript has no class (pun intended).

Prototypal inheritance is actually simpler than classical inheritance once you get your head around it. You don’t need to define classification, so your code is smaller and less redundant since objects inherit from other more general objects. It is a model of differential inheritance; i.e. each level of inheritance only adds the differences with its parent.

Unfortunately, JavaScript is a bit confused about its prototypal nature, and wants to fit in with the other scripting languages by pretending to like The Beatles and by making itself more attractive to classically trained programmers by introducing the new operator.

This means that:

new myConstructor();

produces an object that inherits from myConstructor.prototype.

This indirection means that JavaScript actually has a pretty ugly constructor pattern and most new JavaScript developers never really get to grips with the inheritance model at all.

However, all that has changed with the all singing, all dancing advent of JavaScript 1.8.5 (The New Shit™), which introduces the Object.create method:

var human = {
    legs: 2,
    arms: 2
};

var tim = Object.create(human, {
    tall: true,
    fat: true,
    overInflatedSenseOfSelfImportance: true
});

Mmm tasty, but since JS 1.8.5 only seems to be implemented in Firefox 4 (still in beta), don’t get all excited just yet.

If you want something similar in your own code, you can implement the following for a similar approach (and still kiss goodbye to ever having to use the new operator again):

if (typeof Object.inherits !== 'function') {
    Object.inherits = function(parent, child) {
        function temp() {};
        temp.prototype = parent.prototype;
        child.super_ = parent.prototype;
        child.prototype = new temp();
        child.prototype.constructor = child;
    };
}

Object.inherits(parentConstructor, childConstructor);

What’s more, this DIY version will allow you access to any superclass’ implementations of a particular method like so:

childConstructor.prototype.foo = function(a) {
    // Here’s some of that scope correction we discussed
    // earlier…
    childConstructor.super_.foo.call(this, a);

    // Other code
};

This code is a mix of the goog.inherits function—included in the Closure library—and the Object.create outline by Crockford in his article on prototypal inheritance.

JavaScript design patterns

Taking all this into account, we can start developing some incredibly useful design patterns that make use of prototypal inheritance, closures, and JavaScripts nuances of scope.

In fact, several have already been developed within the JavaScript community:

JavaScript namespacing

To avoid the perils of globally scoped variables and functions, it is advisable to create a single global object for the purposes of namespacing the rest of your code. This is relatively simple to achieve:

var NEF = window.NEF || {};

This command tests for the existence of a NEF object at the global scope, and if evaluated to true, returns that object. Otherwise, it creates a new object using the object literal syntax.

You may now assign any further variables or modules to your namespace:

NEF.myAttribute = ‘foo’;
NEF.myFunction = function() {
    …
};

Module pattern

The JavaScript module pattern was first proposed by Doug Crockford as a means of enforcing public and private object members through the use of closures.

My preferred variation on the pattern is such:

NEF.Module = function() {
    // Private members
    var privateAttribute;

    function privateMethod() {
        alert('Private method called.');
    }

    var pub = {
        // Public members
        publicAttribute: true,

        publicMethod: function() {
            // Private members are in scope here

            privateMethod();

            // Public members are addressable through the 'pub' object.

            pub.publicAttribute = false;
        }
    }

    return pub;
}();

This method simple uses a closure to maintain private variables in the scope of the returned pub object. The trick of this technique is the use of the (), right at the end of the code, after the parent function definition, which causes the function to run immediately and return the pub object.

jQuery plugins

The jQuery plugin architecture also makes use of closures to do something quite similar to the Module Pattern above. However, jQuery plugins are specifically namespaced to the jQuery object itself:

(function($) {
    // Private members
    var debugMode = false;

    function debug(msg) {
        if (!debugMode) { return; }
        if (window.console && window.console.log){
            window.console.log(msg);
        } else {
            alert(msg);
        }
    }

    $.fn.extend({
        myPlugIn: function(config) {
            var defaults = {
                …
            };

            if (config) {
                $.extend(defaults, config);
            }

            this.each(function() {

            });

            return this;
        },

        publicMethod: function() {
            …
        }
    });
})(jQuery);

Alternatively, should you wish to only include a single public method, you can avoid jQuery.fn.extend by instead making use of jQuery.fn for definition:

(function($) {
    // Private members
    var debugMode = false;

    function debug(msg) {
        if(debugMode && window.console && window.console.log){
            window.console.log(msg);
        } else {
            alert(msg);
        }
    }

    $.fn.myPlugIn = function(config) {
        var defaults = {
            …
        };

        if (config) {
            $.extend(defaults, config);
        }

        this.each(function() {

        });

        return this;
    };
})(jQuery);

In this code we can see that jQuery is passed to an anonymous function, that is run immediately, as the parameter $. The anonymous function provides a scope block for the plug-in code, thus preventing potential headaches from variable naming clashes across shared code. The plug-in functions themselves are then created as closures so that they have access to the private variables and functions within that outer anonymous function. These plug-in variables are then bound to the passed in jQuery instance $ using jQuery’s own built in extension functions.

This is actually quite a clever use of closures, although it does have the potential for memory leaks and excessive memory usage if variables and references aren’t kept in check. With that in mind, it’s often a very good idea to profile your jQuery plugins to understand what might need tidying up.

Custom events

Most modern JavaScript libraries include a mechanism for defining your own custom events. A custom event is merely a bespoke event, defined in your code, that other event-handler functions may be bound to. This custom event may then be triggered by you at any given point of execution in the code.

The custom event architecture is an implementation of the Observer Pattern, in which an object maintains a list of dependant “observers” which it notifies automatically of any state changes. In JavaScript, the object maintaining the list is our event, and the “observers” are the event handlers.

Using custom events in your own code provides a useful binding for other developers’ code. The event itself is loosely coupled to the event handlers, thus, additional event handlers can be added or removed by third-party code.

For more information on custom events, I’d recommend having a look at the documentation for the library of your choice. Here are few links:

• jQuery custom events: .bind()
• YUI2 custom events: The CustomEvent object
• YUI3 custom events

Summary

So that’s the technical addendum to my 2006 post. Hopefully, that should serve to bring the article up to date, and correct a few of my previous errors. As always, comments and corrections are welcome via the comment form below.

Originally I had intended posting this article in two parts, however, it has continued to grow even as I write it. For this reason, the third and final part of this follow-up series will look at what’s on the horizon for JavaScript development, including how GoogleBot deals with JavaScript, the importance of supporting a core experience (where JavaScript is unavailable), server-side JavaScript, and architecting JavaScript applications.

When I read that article now, however, it bothers me. The tutorial is still good although the information within is somewhat dated; and my personal experience, knowledge, and general approach to writing JavaScript has changed quite drastically. The fact that the article still receives a consistently high number of unique visitors on a daily basis, when I no longer agree with all the content within it, bothers me even more. With that in mind, I have decided to write an update that looks at OOJS as I would currently use it.

The resulting post has become quite extensive, so I’ve decided to split it into two separate articles. This first one will cover some development theory, whilst the second will dive into JavaScript coding specifics.

A note on the name

A friend of mine recently quoted this little gem in his Twitter stream:

Java is to JavaScript as Ham is to Hamster.

Enough said.

Is it object-oriented?

In my original article I stated that JavaScript was not an object-oriented language, but rather an object-based language. This was entirely unfair on JavaScript, and I’d like to fix that:

JavaScript is an object-oriented language. However, it breaks away from more conventional object-oriented languages by implementing prototypal inheritance, instead of classical inheritance. This is a Very Good Thing™ (although that seems to be a matter of opinion). More on that later.

First principles for JavaScript programming

Before I start, let me be clear that there are first principles of programming that are language agnostic. We’re going to look at a couple of those, but I’d also like to discuss a few of the more JavaScript specific principles first; those that relate to the cross-browser web standards environment. Finally, I’m aware that I’m really only scratching the surface of some of these topics. I don’t really want to muddy the water here by waxing lyrical on good development practices, so if you’re after more depth, I’d recommend researching them via the search engine of your choice:

Proper separation of the behavioural layer

Above everything else, it’s important to keep your content and markup (HTML), presentation (CSS), and behavioural (JavaScript) layers separate. Why is that important? Well if one or more of those layers are missing or broken (with the obvious exception of the core HTML), the others should still function as intended. Ultimately this makes presentation and behaviour optional, and a user might turn them off—via their browser settings—should they so desire. Alternatively, the user may include custom presentation or behaviour to aid a particular use-case.

In JavaScript, proper separation requires making use of the DOM to bind behaviour to HTML elements via element identifiers (i.e. the id or class attribute) in your source code. The alternative would be to write JS directly into the HTML, via event attributes such as onClick=”” or via the javascript: pseudo-protocol in the href attribute. This is not a good practice and I heartily recommend against it.

Graceful degradation

Graceful degradation is a well known software engineering concept which involves writing your code to take advantage of awesome feature X, unless awesome feature X is unavailable, in which case degrade to use slightly-less-awesome feature Y (assuming that too is available).

In web development terms this might mean making use of an amazing JavaScript date picker widget on a text-based input box, and just degrading to server-side date validation if JS is not turned on in the browser. It could also mean making use of the latest CSS3 styling techniques but degrading to use CSS2 techniques in less capable browsers.

In short; build everything in the most up to date browser, making use of all it’s wonderful modern features, and then go back and make sure the site is still usable when any of those features are not.

The problem with approaching the issue from this direction, however, is that you are saying to your users: “You (or your browser) are incapable of handling the full experience we want to present, so here’s a cut-down version.” This pretty much flies in the face of user-centric design, and good user experience. With that in mind, we’d be better using…

Progressive enhancement

Progressive enhancement involves approaching the problem from the other direction. You should design for the user-agent with the least capabilities and add functionality for more capable browsers afterwards.

In web terms this means developing and designing with nothing but the base features of HTML in mind, and then enhancing those features (or the features of the browser interpreting that HTML) by attaching CSS and JS to the HTML via element identifiers like IDs and classes.

The final outcome of these two approaches might be very similar, but the subtle difference is that you are giving more attention to the less capable user-agent when you progressively enhance.

The most common use-case for progressive enhancement is the support of a non-JS experience.

DRY (Don’t Repeat Yourself)

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. This means abstracting code into shared functions and objects whenever you find you are repeating yourself, and attempting to maintain a single source of truth in every aspect of your system.

DRY is a well known paradigm in software engineering, and as such, should be applied in every detail of your JavaScript code.

Refactor early, refactor often

Further to the principle of DRY, it is important that if you spot a potential issue in your JavaScript code you fix it. The more small refactors you do, the less time-consuming big refactors you are likely to need to do later on.

Once you’re refactoring often, you’ll be able to…

Make it work, make it right, make it fast

The first iteration of your code should only look to reach the level of functionality defined in the functional specification. Once this has been achieved, refactor to improve the way it works—so the code is “right” in your opinion. This may very well mean a complete overhaul of architecture, but you will be able to concentrate much more specifically on that since you already have it working. The final stage in this development cycle is to optimise your code for performance and efficiency; premature optimisation is a fundamental mistake in development.

Useful resources

When it comes to general development, there are a veritable plethora of resources out there, but my recommended starting point is the book The Pragmatic Programmer, by Andrew Hunt and David Thomas. This book outlines quite a few paradigms that should get you thinking about the way you develop.

Important things to understand

Pure JavaScript

In this age of JavaScript libraries and frameworks, it’s important to make sure you understand core JavaScript functions, objects, and methods. Although your library of choice may clean up any cross-browser issues you may encounter, it is always important to understand exactly how you are interacting with JavaScript as a language.

Useful resources:

The Mozilla Developer Centre section on JavaScript is an invaluable reference resource when writing pure JavaScript. Also, make sure you own a copy of JavaScript: The Definitive Guide by David Flanagan.

The DOM

The Document Object Model is an entirely separate beast to JavaScript, but is implemented natively within it. There are also DOM libraries for other languages that implement the W3 DOM specification when dealing with XML and SGML files.

Understanding the DOM in JavaScript is essential when designing and developing interactions with your HTML and CSS. Thankfully all JavaScript libraries abstract out the pitfalls of DOM scripting so that you don’t have to, but as before, it’s still important for you to understand how so that you can maximise your efficiency in using said library.

Useful resources:

Once again the Mozilla Developer Centre provides an excellent DOM reference section, although it is slightly skewed in favour of the Gecko browser engine. You can also find plenty of information on the DOM at the W3C site.

Interaction with the browser

When writing client-side JavaScript, it is important to take into account how HTML, CSS, and JavaScript interact with the browser directly. At every available opportunity, you should attempt to make sure you are not contradicting the browser, and that you are not rewriting interactions that are already well handled by the browser and operating system.

A good example of this is to make sure you do not break the “back” button. Often this can be achieved by simply using the window.location.replace() method to control which pages appear in the browser history.

Libraries

Using libraries in JavaScript has become standard practice. A JavaScript library exists to save time and effort, and to provide a single source of truth (as discussed earlier) for many common tasks within that language.

A JavaScript library provides you a toolbox full of handy devices to make your life easier. It needs to be treated as such, and not as a language in its own right. It is very important to understand the core structures of JavaScript, and how the library of your choice interacts within those structures and your own code.

Every library is different and has its own pros and cons. I’m not going to go into my opinion of those here; perhaps that’s something for another post. They do, however, all interact somewhat differently with JavaScript, and it’s important to understand how the library you choose does that specifically.

Summary

Hopefully that should get you in the right frame of mind to develop high quality JavaScript code. In the second half of this article I will be looking at specific use of JavaScript in regard to object-orientation.

Continue reading part 2 of my object-oriented JavaScript follow-up…

I really really need to move off of WordPress.

Needless to say, the completed version of that post should be published very soon!

Recently, I’ve been building a new blog platform, in Django, called “nef-blog”. It’s nothing special; just a quick self-build solution that will get me off of WordPress. However, I’m still not entirely happy with it, since it will still be building my blog pages at request time (otherwise known as “frying” pages). This seems like a needless overhead and, for good performance on popular posts (I do have some), will probably still require some form of caching solution. I’d much rather have the choice of implementing a mixed fried and baked solution—where “baked” pages are generated by some form of printing process, and the output is stored on the file system and served at request time.

Several of my peers have also recently been building baking (or “static CMS”) solutions—most of which are available for perusal on GitHub, despite being in varying stages of completion:

• “Lanyon”, by Steve Webster
• “Fallow”, by Mike West
• “Flourish”, by Mark Norman Francis
• “AYM CMS”, by Will Larson
• “Jekyll”, by Tom Preston-Werner
• “Hyde”, by Lakshmi Vyas

This has inspired me to attempt to develop a new CMS; but before I do that, I thought I’d lay down a sort of treatise of things to take into account when designing and developing a CMS. These are simply my own thoughts on the subject, and I’d definitely welcome some discussion; I’d definitely like to be able to update this post in the future with new information garnered from the web developer community.

Isabella Ada Huegdon (5lb 10oz) and Amélie Isla Huegdon (5lb 5oz) arrived at 10:02am and 10:27am respectively on the 23rd of May, 2007. I haven’t had time to upload loads of pictures yet, but watch my Flickr stream; there are a few there already.

I’m very happy to be a Dad although it’s pretty hard going at the moment; in fact, I reckon one baby must be an absolute doddle. To be fair though, Meegan is doing the majority of the work at the moment since I leave for work at 6:30am and get home at 8pm.

Anyway, as far as the blog is concerned, normal service will resume shortly (I’m writing a couple of posts at the moment).

Last night I went to see Cirque du Soleil perform “Alegria”, their new show, at the Royal Albert Hall.

It was my mother-in-law’s birthday; but we hadn’t told her where we were going so, when her and Meeg turned up outside my office late yesterday afternoon, she was none-the-wiser. When I finally made it downstairs to the street, they were both clearly very excited (although I’m not sure whether that was due to what might be coming or the fact that they’d just spent 5 or 10 minutes staring into the window of Angels’ Fancy Dress shop).

We all decided we were pretty hungry so I took them to Govinda’s Krishna Restaurant on Soho Street, because the mother-in-law is vegetarian. Govinda’s is an excellent place to eat whether you’re veggie or not – in fact, I’d actually had lunch there with Stuart and Tristan earlier in the day. The food is fantastic Indian vegetarian fare and the prices are ridiculously low. In all honesty, I can’t recommend it enough!

Once we’d finished our meal, we still had some time to waste so I took them on a leisurely stroll down Shaftesbury Avenue to Piccadilly Circus. We then continued our meanderings down Piccadilly past Fortnum & Mason’s (who happen to have a cool “Alice in Wonderland” themed window display at the moment) and The Ritz (considering how expensive their hotel is, you’d think the website would be better eh?).

It was at this point that I realised we’d become one of those groups of people I so despise when I’m in a rush to get to the station after a long day’s work. You know; the ones who wander aimlessly clogging up the pavement. At this revelation (and also since my pregnant wife was getting a little tired), I hailed a cab and we whisked the mother-in-law off to the Albert Hall.

Once we’d found our seats in the circle, we settled in for an excellent show – although sadly, the back parts of the stage were somewhat obscured from our view. However, this didn’t spoil the show too much and certainly didn’t hinder our enjoyment.

I’d never seen Cirque du Soleil before and was quickly dazzled by their fantastic costumes and orchestration. The line-up included some excellent clowns, an aerial high bar, tumblers (who used a really cool cross-shaped trampoline called a “Power Track” to enhance their flips and leaps), a hand-balancer, fire-jugglers, a flying-man (a guy on a bungie-cord), russian bars, manipulation, contortion and a synchronised trapeze. Their website has plenty of information about the acts in the show.

We thoroughly enjoyed the show and would recommend anyone else to go see it. I have read reviews that say it’s nothing new if you’ve seen Cirque du Soleil before – so as newcomers, we might just be dazzled by their grace, acrobatics and skill.

All in all, it was an excellent night and the mother-in-law appreciated it greatly.

The exponential growth of processor speeds and memory and hard drive sizes sometimes catches me off guard. I mean, I’m well aware of Moore’s Law; but since I can still remember the days of programming with only 16k at your disposal, the mind boggles!

Jesse James Garrett raises an interesting point whilst contemplating The Desktop Terabyte.

Still, at least server-side back-up scripts won’t cause so many problems with all that lovely extra space… Uh… Right Stu?

My website has been down for a couple of days due to a couple of server issues, but it’s all back up and running now thanks to some hard work from my server-buddy, Stu.

Needless to say, having spent the Christmas period away from my computer and the blogosphere, I have returned revitalised and refreshed. I’m also pretty good at Viva Pinata now as well.

So, during the train ride into work this morning, whilst staring out the window at an awesome morning mist, my thoughts turned to API’s; more precisely, to writing an application entirely based around an API. I was thinking about how fun it would be to try to write an effective API and then use PHP and JavaScript to manipulate that API to build an application. I also thought it would be an interesting exercise in best-practices; from planning and documentation, through to responsibly using AJAX.

Woah! Where did that come from?

I guess I’m partly spurred on by Jeremy Keith‘s excellent presentation at d.Construct06 entitled “The Joy of API“, as well as Drew McLellan’s presentation “Can your website be your API?” at the last WSG London meet (listen to it via the WSG podcast). API’s are sexy – all the popular kids have them in one form or another; from REST style Flickr and de.licio.us through to the Microformat heavy Corkd. It’s all happening out there and I want a piece of the action.

So what’s the big idea?

As an amateur cook, I’ve recently been thinking about purchasing a scrap-book so that I can collect and collate recipes, however, I’d much rather be able to do this online since I tend to plan meals in my head whilst I’m at work. There are a huge number of recipe sites out there but they tend to be over complicated, drowning in adverts, ugly and not quite what I want – so I thought, what the heck, I’ll write one and try to do a good job! What’s more, I’ll try and work to a Web2.0 ethic and promote a community environment.

I’m well aware that I might crash and burn half way through the process – but since I’m approaching this as a learning experience, I’m going to get something out of it even if it is a few harsh lessons.

What do you hope to learn?

Quite a lot really. I’m interested in improving my understanding of user interface design, of web application design, of information architecture for the web, and, at a technology level, of Microformats and the YUI. I’m also looking to discover new things about the languages I’ll be using; from the potential minefield that is PHP through to the responsible use of JavaScript, as mentioned earlier.

So what next?

Over the next couple of days I’ll start to look at planning the project and I’ll try to blog the process. I’ll also include all my documentation and will hopefully get some feedback (including ideas – let’s open up the floor here).

Hopefully, by the end of this, I’ll have learnt some stuff and created a handy application.