So, following on from my recent post about turning jQuery code into richer, unit testable plugin code, I thought I’d describe the quick process of doing so here. (It’s worth reading Snook’s post first though!)

The general steps discussed to achieve this are as follows:

1. Add additional keyboard accessibility
2. A first attempt plugin
3. A plugin that might be unit testable

Add additional keyboard accessibility

I posted a comment on Snook’s post to say additional hover and blur events should do the trick, so here is an example applied to one of the four demo menus he had with those events added:

$('#d a')
    .css( {backgroundPosition: "0 0"} )
    .mouseover(function(){
        $(this).stop().animate({backgroundPosition:"(0 -250px)"}, {duration:500})
    })
    .mouseout(function(){
        $(this).stop().animate({backgroundPosition:"(0 0)"}, {duration:500})
    })
// I added these event handlers:
    .focus(function(){
        $(this).stop().animate({backgroundPosition:"(0 -250px)"}, {duration:500})
    })
    .blur(function(){
        $(this).stop().animate({backgroundPosition:"(0 0)"}, {duration:500})
    })

A first attempt plugin

The above code as a plugin might look something like this:

(function($) {
    $.fn.animatedBackground = function(options) {

    // build main options before element iteration by extending the default ones
    var opts = $.extend({}, $.fn.animatedBackground.defaults, options);

    function startAnimation() {
        $(this).stop().animate(
           {backgroundPosition:opts.backgroundPositionStart},
           {duration:opts.duration}
        );
    }

    function stopAnimation() {
        var animationConfig = { duration:opts.duration };
        if (opts.complete)
            animationConfig.complete = opts.complete;

        $(this).stop().animate(
            {backgroundPosition:opts.backgroundPositionEnd},
            animationConfig
        );
    }

    // for each side note, do the magic.
    return $(this)
        .css( {backgroundPosition: opts.backgroundPositionInit} )
        .mouseover(startAnimation)
        .mouseout(stopAnimation)
        .focus(startAnimation)
        .blur(stopAnimation)
    };

    // plugin defaults
    $.fn.animatedBackground.defaults = {
        backgroundPositionInit : "0 0",
        backgroundPositionStart : "(0 0)",
        backgroundPositionEnd : "(0 0)",
        durationStart : 500,
        durationEnd : 500,
        complete : null
    };
})(jQuery);

The above is just a quick 2 minute thing — I am sure with more thought the plugin options could be made even more flexible. But this will do for the purpose of this post.

For each of the 4 demo menus Snook provided, you could then call them as follows:

$(function(){
    $('#a a')
        .animatedBackground(
            {
                backgroundPositionInit : "-20px 35px",
                backgroundPositionStart : "(-20px 94px)",
                backgroundPositionEnd : "(40px 35px)",
                durationEnd : 200,
                complete : function(){
                    $(this).css({backgroundPosition: "-20px 35px"});
                }
            }
        );

    $('#b a')
        .animatedBackground(
            {
                backgroundPositionStart : "(-150px 0)",
                backgroundPositionEnd : "(-300px 0)",
                durationEnd : 200,
                complete : function(){
                    $(this).css({backgroundPosition: "0 0"});
                }
            }
        );

    $('#c a, #d a')
        .animatedBackground(
            { backgroundPositionStart : "(0 -250px)" }
        );
});

(Examples c and d are combined with one selector, while a and b each have more complex options.)

In the “simple” cases (c and d) a very small amount of code is needed to use the plugin. For (a and b) if you were only going to use this once, it might be questionable whether the plugin for this is worth the effort!

Unit testable plugin?

Some plugins might be so small that unit testing them may not seem beneficial or worth the effort. In this particular case, it is not clear if it is necessary. However, for the purpose of this post at least it may be a useful exercise. So, these might be some things to bear in mind:

• The bulk of the plugin relies on animate() which works asynchronously. Unit testing asynchronous calls can be tricky with QUnit. More importantly, we are not trying to unit test animate() but our plugin code instead.
• The function handler for each mouse/focus/blur event could be made into a default plugin function
• Unit tests can then replace the default function with a mock function to confirm that the rest of the plugin works with the various configuration options passed in.

To achieve the above, a simple step might just be to make the private startAnimation() and stopAnimation() methods public.

This can be done a few ways, e.g. keep those private methods and make them call the public ones, or wherever the private ones are called, make them call the public ones, etc.

The two public methods would look something like this:

$.fn.animatedBackground.startAnimation = function($el, opts) {
    $el.stop().animate(
        {backgroundPosition:opts.backgroundPositionEnd},
        {duration:opts.duration}
    );
}

$.fn.animatedBackground.stopAnimation = function($el, opts) {
    var animationConfig = { duration:opts.duration };
    if (opts.complete)
        animationConfig.complete = opts.complete;

    $el.stop().animate(
        {backgroundPosition:opts.backgroundPositionEnd},
        animationConfig
    );
}

Here’s a page with a unit testable version of the plugin which also has the original menu examples

Was it worth adding extra code to make it unit testable?

The testable plugin version is a bit larger than the original (ignoring minification and gzipping benefits to remove a lot of the difference).

Was it therefore worth changing in this way from the original?

In my opinion, the initial plugin version would probably suffice, especially if likely to be used across a few small projects.

If, on the other hand, you were going to use it in a more critical scenario, then unit testing what you can could be useful.

A principle of test driven development is to write unit tests first. In this case as it was existing code, it seemed okay to do it in the order described above. Furthermore, sometimes it feels tricky to always stick to that principle religiously, and writing unit tests afterwords might be okay if the plugin is smallish, perhaps?

Summary

So, many thanks for Jonathan Snook for his post. That technique is useful for me in some other projects.

This post hopefully shows that even small snippets of code can be turned into a plugin, sometimes unit testable ones. Whether that is worth your efforts depends on your need and audience.

It’s by-line of “write less, do more” really seems apt.

But sometimes, by writing just that little bit extra, you can do even more.

For example, I often try to do the following:

• Make most jQuery code into reusable plugins
• Use the jQuery plugin development pattern for added flexibility
• Use QUnit to unit test JavaScript
• Combine the two approaches to drive out a richer API for the plugin

By unit testing with QUnit, I find I often need to trigger additional events or add additional code from within the plugin so the test can be meaningful.

But this extra code isn’t only useful for testing, it becomes a useful part of the plugin’s API, improving its functionality and flexibility without sacrificing maintainability and readability of the code.

I’ll try to demonstrate that in this post.

Make most of your jQuery code into reusable plugins

In many cases, where there is a block of jQuery code initializing something, it is a candidate for a plugin.

It took me a little while before I gave jquery plugins a go, thinking it will be complex and I won’t have time. But, it turns out to be really simple, elegant and useful for both simple and complicated scenarios.

Example to create a dynamic side note toggler

Lets take a simple example for illustration: suppose I have some HTML that acts as an aside, or side note, and that I want to toggle its appearance.

Lets say we agree this kind of HTML format for it (or microformat):

<p>Some text before the side note.</p>

<div class="side-note">
	<p>Any HTML could go here including</p>
	<ul>
		<li>Bulleted lists</li>
		<li>Tabular data</li>
		<li>Images</li>
	</ul>

	<div class="side-note">
		<p>Even nested side notes, if that is of any use!</p>
	</div>
</div>

<p>Some text after the side note.</p>

The first way I’d do it might be something like this:

$(document).ready(function() {
    $('.side-note').each(function() {
        $(this)
            .addClass('dynamic-side-note')
            .hide()
            .wrap('<div class="dynamic-side-note-container"></div>')
            .before('<h3 class="toggler"><a href="#">Side note:</a></h3>')
            .parent(0).find('> h3.toggler > a').click(function() {
                $(this).parents('.dynamic-side-note-container').eq(0).find('> .dynamic-side-note').slideToggle();
                return false;
            });
    });
});

I could have added a click event handler to the h3 header above, but using an anchor adds keyboard accessibility.

(The CSS selector could also be improved, e.g. to narrow it down to only side-notes in some content div, e.g. $('#content .side-note').)

Here is a working example

As a simple jQuery plugin

The above works. But, we can move most of the above code into a jQuery plugin.

Why bother? We can gain a bit more flexibility, such as the ability to use any selector, not rely on a side-note class. We could pass in other parameters such as what the text for the side note toggler/header should be, etc.

As a first attempt, the plugin might look something like this:

$.fn.sideNotes = function() {
    // returning this way allows chaining
    return $(this)
        .addClass('dynamic-side-note')
        .hide()
        .wrap('<div class="dynamic-side-note-container"></div>')
        .before('<h3 class="toggler"><a href="#">Side note:</a></h3>')
        .parent(0).find('> h3.toggler > a').click(function() {
            $(this).parents('.dynamic-side-note-container').eq(0).find('> .dynamic-side-note').slideToggle();
            return false;
        });
};

We then just need to invoke the plugin:

jQuery(function() {
    $('.side-note').sideNotes();
});

(Note how you could use any selector now not just .side-note as above.)

Here is a working example using the simple plugin

Plugins also make it easier to pass in more options for configuration. The next example uses a useful pattern for plugin development that also shows a nice way to handle plugin options:

Use the jQuery plugin development pattern for added flexibility

The post, A Plugin Development Pattern (for jQuery), from the Learning jQuery blog is really useful.

It provides a good way to write plugins that also get the following features:

• Configurability by passing in options
• Default options to keep invoking code small and neat
• A closure where you split your code out into manageable private functions, etc., if you need
• Ensuring that your plugin support chaining
• And more

Using some of those ideas, here is what we might come up with for the sideNotes plugin:

(function($) {
    $.fn.sideNotes = function(options) {

    // build main options before element iteration by extending the default ones
    var opts = $.extend({}, $.fn.sideNotes.defaults, options);

    // for each side note, do the magic.
    return $(this)
        .hide()
        .wrap('<div class="dynamic-side-note"></div>')
        .before('<h3 class="toggler"><a href="#">' + opts.sideNoteToggleText +'</a></h3>')
        .parent(0).find('> h3.toggler > a').click(function() {
            $(this).parents('.dynamic-side-note').eq(0).find('> .side-note').slideToggle();
            return false;
        });
    };

    // plugin defaults
    $.fn.sideNotes.defaults = {
        sideNoteToggleText : 'Side note:'
    };
})(jQuery);

And invoking the plugin is the same as before:

jQuery(function() {
    $('.side-note').sideNotes();

    // or overriding the default side note toggle text:
    // $('.side-note').sideNotes({ sideNoteToggleText : 'As an aside:' });
});

Here is a working example using the plugin pattern

Unit testing the jQuery plugin

As the plugin code is reasonably well encapsulated, we can create some unit tests for this plugin.

Unit testing jQuery (as with any code) gives you confidence in maintaining it. For example, when refactoring code, unit tests give you confidence that you can do it without breaking things. Plugins, almost by definition are good candidates for unit testing.

Examples of unit tests for this plugin

Our example side note plugin is quite simple, so the unit tests will likely be small in number. Types of tests we might include are the following:

• Test that we can expand/collapse a side note
• Test that we can expand/collapse a side note many times and ensure the toggle state reported is correct each time
• Test that when the side note plugin has run, all the side notes are collapsed initially
• Test that we can change the toggle text to something else

And so on.

Remember, the unit tests should not test the slideToggle() method we happened to use (as that should be unit tested itself, and we may use other ways of toggling the side note in the future). Instead, we just need to unit test our code and plugin functionality.

So ideally, we might even want to “mock” the slideToggle(), if necessary.

Use QUnit to unit test JavaScript

QUnit is a unit testing framework, used internally by jQuery itself for all its core JavaScript, and now opened up and documented for others to use, too. It is a simple framework to support the creation and execution of tests.

The tests are run in a browser. You could automate it against all your target browsers by using something like Selenium.

The framework is in its early days (a setup and teardown set of methods would be nice, for example), but is rich enough to get started with it.

Here is a QUnit test page for the side note plugin

(I included a manual test area as this can sometimes be useful where visual confirmation is useful or automated tests of some parts is not possible/easy. Having this all in one place can be handy.)

Using unit tests and plugins helps create a richer API for the plugin

To write testable code, you may find you need to provide more hooks in the code. Yet, you probably don’t want to pollute your code so much that it is detrimental to performance or maintainability.

Triggering events on the plugin for added flexibility

In the unit test example page, how did we manage to get unit tests to confirm a side note had been toggled when we didn’t have any callback for it?

The first idea people might have is to pass a callback that a plugin user can point to in the options when invoking the plugin, something like this:

jQuery(function() {
    $('.side-note').sideNotes(
        {
            toggled : function() { console.log('side note was toggled'); }
        }
    );
});

That looks useful; the unit test can provide a callback when it invokes the plugin.

However, that limits us to just one observer, the one that invoked the side note plugin in the first place.

But we can go one step further: trigger events. This allows more than one observer to watch for the event. This is achieved using jQuery’s trigger() and bind() methods.

By having unit tests watching for these events, it does not distort the plugin code; it enhances its API making the event useful for a real plugin user, if they need it.

In our side note plugin example, when we call slideToggle() we can trigger an event when the toggling has completed:

// all the stuff that gets to the
// slide toggle bit comes here!
.slideToggle( function() {
    $(this).trigger('sideNoteToggled');
});

If your code cares when this happens, you can bind to this event, something like this:

$('.side-note').bind('sideNoteToggled', eventHandlerGoesHere);

(A fuller example below uses trigger() to also pass the expanded/collapsed state in conjunction with some ARIA information.)

Providing default implementations that can be replaced (or mocked for unit testing)

One particular challenge I had with unit testing this side note example was that the slideToggle() method used by the plugin, internally runs asynchronously (using setTimeout etc).

Writing normal unit test code means the test can finish before the animation has run.

Even though I tried to use setTimeout() on the tests themselves to try and make them wait for the sideNote to finish toggling, and passing in the fastest speed possible to the slideToggle method, it wasn’t always right, and not consistent across all browsers.

This gave me the opportunity to do a few things:

• Encapsulate the call to slideToggle in another method
• Make that method the default implementation, but overrideable
• Use this to provide a mock slide toggler for testing purposes

With jQuery’s plugin architecture providing a default implementation is quite straight forward:

$.fn.sideNotes.toggle = function() {
    $(this).slideToggle(function() {
        $(this).trigger('sideNoteToggled');
    });
};

Mocking the slideToggle() call is nice because we don’t want to test external code in our unit tests; that should have been unit tested by whoever wrote that (the jQuery team I imagine! I’ll have to look at their unit tests when I get a moment to see how they overcome asynchronous issue — there is some mechanism to provide stop() and start() methods for AJAX testing and I tried this here, but still wasn’t getting consistent results).

In our example, we can overwrite the the default toggle method to simply use toggle() instead of slideToggle(), which is a non-animated version that runs and completes immediately.

This makes writing the testing code a bit simpler too. (There are one or two bits that I did that didn’t feel too great in my opinion, such as the way I chose to expose the post toggle action, but that is perhaps for another day to sort out!)

To override the default implementation, you can redefine sideNotes.toggle in your code, something like this:

$.fn.sideNotes.toggle = function() {
    $(this).toggle().trigger('sideNoteToggled');
};

Example QUnit test code

So taking the above considerations this is what we might have in our QUnit unit test code:

This code block shows a test util object to help instrument the test, and then at the bottom, an example of a mock object to replace the slideToggle() call.

(function(){
    var testUtils = {
        isExpandedCount : 0,
        isCollapsedCount : 0,

        defaultTestOptions : {
            selector : '#example .side-note',
            sideNoteOptions : {},
            speed : 'fast'
        },

        // a crude setup like method, which QUnit currently doesn't have
        init : function(options) {
            testUtils.reset();

            var opts = $.extend({ sideNoteOptions : {} }, testUtils.defaultTestOptions, options);

            // tests assume the relevant HTML is present on the page the test is running
            $(opts.selector)
                .bind('sideNoteToggled', testUtils.sideNoteToggled)
                    .sideNotes(opts.sideNoteOptions);

            return $(opts.selector);
        },

        sideNoteToggled : function(event, isExpanded) {
            isExpanded ? testUtils.isExpandedCount++ : testUtils.isCollapsedCount++;

            $(event.target).trigger('sideNoteToggleCaptured');
        },

        // until there is an explicit tear down method this will have to do
        reset : function() {
            $('#example .side-note').unbind('sideNoteToggled');
            testUtils.isExpandedCount = 0;
            testUtils.isCollapsedCount = 0;
        }
    };

    // mock the slideToggle. We are not testing that.
    function mockSideNoteToggle() {
        $(this).toggle();

        $.fn.sideNotes.toggled.call(this);
    }

    // keep the original implementation if we want to use it later
    $.fn.sideNotes.originalToggler = $.fn.sideNotes.toggle;

    // override the default toggle method with the mock
    $.fn.sideNotes.toggle = mockSideNoteToggle;
})();

We can then write unit tests, such as this one (note this code would go inside the anonymous function used above):

module("Single toggle tests");

test("Test side note is expanded when toggled", function() {
    var $sideNote = testUtils.init();

    $sideNote.each(function() {
        equals($(this).attr('aria-expanded'), 'false', "Side not starts as collapsed");
    });

    $('#example')
        .find('.side-note:eq(0)').bind('sideNoteToggleCaptured', function() {
            equals(testUtils.isExpandedCount, 1, "A node has been expanded");
            equals(testUtils.isCollapsedCount, 0, "No nodes have been collapsed after initialization");
            equals(this['aria-expanded'], true, "Node’s aria state is expanded");
        })
        .end()
            .find('.toggler > a:eq(0)').click();
            // calling click() is like simulating the user action to start the test
});

In the above example, the following is happening:

1. The call to init() creates/initializes the sideNote plugin
2. We then assert that the ARIA state reports each side note is not expanded
3. We then find each side note and bind to the sideNoteToggleCaptured event (which is raised by the unit test utility shown earlier, not by the plugin itself)
4. We then simulate a user action by finding the toggler and clicking it
5. The simulated click() makes the plugin eventually trigger the sideNoteToggled event, which the testUtils object will catch.
6. The test util will catch that event and update the various testing counters and itself trigger the sideNoteToggleCaptured event.
7. Finally at this point, we can run our assertions, such as confirming the expected number of times the side note was expanded/collapsed and what the expected ARIA state should be (in this example seen by the use of the equals() function).

See the full example for more unit tests

The additional tests in the full example also show the side note being dynamically created per test run, so you don’t always have to have the HTML set up exactly as needed for every test, manually.

The unit test code in that example can probably be further improved by refactoring those test() functions into a helper function where you pass in callbacks to run when the test has completed, how many clicks you want to invoke, etc, but that is for another time!

Final plugin code

Here is the final plugin code (with some additional options not discussed above):

(function($) {
    $.fn.sideNotes = function(options) {

        // build main options before element iteration
        var opts = $.extend({}, $.fn.sideNotes.defaults, options);

        // iterate and process each matched element
        return $(this)
            .addClass('dynamic-side-note').hide()
            .attr('aria-expanded', false)
            .wrap('<div class="dynamic-side-note-container"></div>')
            .before('<' + opts.toggleElement + '><a class="toggler" href="#">' + opts.sideNoteToggleText +'</a></' + opts.toggleElement + '>')
            .parent(0)
                .find(opts.toggleElement + '.toggler > a')
                    .click(doToggle);

        // example of private method
        function doToggle() {
            $(this)
                .parents('.dynamic-side-note-container').eq(0)
                    .find('> .dynamic-side-note').each( function() {
                        $.fn.sideNotes.toggle.call(this, options);
                    });

            return false;
        }
    };

    // plugin defaults
    $.fn.sideNotes.defaults = {
        sideNoteToggleText : 'Side note:',
        speed : 'normal',
        toggleElement : 'h3'
    };

    // default implementation for the toggler (public. i.e. overrideable)
    $.fn.sideNotes.toggle = function(options) {
        $(this).slideToggle(options.speed, $.fn.sideNotes.toggled);
    };

    // default callback when toggle completed (public. i.e. overrideable)
    $.fn.sideNotes.toggled = function() {
        this['aria-expanded'] = this['aria-expanded'] === true ? false : true;

        $(this).trigger('sideNoteToggled', this['aria-expanded']);
    };
})(jQuery);

Is the additional lines of code for a plugin worth it?

The plugin used in the unit tested example is larger in terms of lines of code than the very first attempt, above.

In this case, the lines of code is still quite small, and as plugins get even larger the percentage difference is likely to be small (the size difference is more noticeable in smaller code samples, such as this contrived side note example).

Minimizing and gzipping JavaScript, plus using far future expires header for better caching would further reduce the percentage difference in file sizes of the two approaches.

Depending on your needs, this may be a reasonable trade-off in return for additional flexibility.

Summary

So, in many cases, jQuery code can be made reusable by making it into a plugin. Any time you find yourself writing a block of code, say inside a $(document).ready() block, consider converting it into a plugin and calling it.

When making the plugin, consider the following:

• Provide various options for flexibility
• Write unit tests to test your plugin
• Trigger important events inside your plugin to aide unit testability, and in doing so, increase flexibility of your plugin even more.

When you get the hang of this, it is probably better to write the unit tests before the actual plugin code. This will help focus on what is needed and what the plugin needs to expose in terms of capability. To be honest, at times I have found it easier to retrofit a plugin with unit tests. I probably need to be a bit more disciplined to write tests first!

(While there are a number of enhancements that could be added to this, the main thing I’d probably do is rename the plugin to something more generic than just a side note toggler, but I will leave that for the reader to do, and remember to refactor the unit tests accordingly!)

Hope that is useful?

This will allow you to write web pages that refer to those scripts rather than copies on your own site, reducing your bandwidth, but also leveraging the infrastructure capabilities of Google, such as their content distributed network (which means users would be served those files from a location much closer to them), properly compressed, minified, cacheable files, etc.

In addition, if your visitors have been to other sites using the same technique, they would not need to download the same libraries all over again, and with increasingly rich web sites, these files can get quite large.

So, if you use jQuery, you can use this in your web pages:

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js"></script>

Of course, this is not for everyone, and it may be worth bearing in mind some concerns raised by Peter Michaux, who also provides a useful way to handle the scenario where you think access to Google from the user’s location might be restricted (e.g. blocked from a paranoid office!):

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js"></script>
<script type="text/javascript">
  if (!jQuery) {
    // load from your own server
    document.write('<script type="text/javascript" src="/js/jquery.min.js"><\/script>');
  }
</script>

Still, it could be a useful technique to further improve the download/load performance for a number of sites.

A number of months back, Yahoo was the first to announce something like this when they said they would host their YUI library for you so it is good to see others getting into this.

This post is a summary of day 2, a more technical look at JavaScript and its future.

JavaScript 2 and The Open Web

By Brendan Eich, the inventor of JavaScript.

Good talk on some details about JavaScript 2 which he (and others) have been blogging about recently. He also briefly talked about the “open web” (WHATWG, W3C, etc) versus a “closed one” (Adobe AIR, Microsoft’s Silverlight, etc), which he has also blogged about previously.

He also talked about some of the language features being proposed for JavaScript 2 which would make it look much more object-oriented (namespaces, classes, packages, generics etc). He said the main drivers for JavaScript 2 were better security, better APIs and better programming language support.

Why are these needed? He felt users deserved more support in the language. He lamented that the combination of Microsoft’s domination combined with Netscape’s self-destruction had made the web stagnate. JavaScript hasn’t really changed that much in those years. As web apps were getting more common place, some of these new features could be more important.

A point he and others have made is that while there are better languages out there, most have not really been used as widely as JavaScript, especially from the kind of wide user base that JavaScript has, so the perceived weaknesses of JavaScript can also be its strengths (something Douglas Crockford looked into further — more below!).

Update 1: he has posted slides together with notes and commentary. A useful read.

Update 2: Ajaxian has a decent look at a specific aspect of his talk: JS code bloat and JS2′s improvement, and the performance benefits of JITting.

(Here’s a decent set of slides on the new features being considered in JavaScript 2, actually by John Resig, the next speaker!)

Building Interactive Prototypes with jQuery

By John Resig, inventor of jQuery.

I think this was one of my most favourite sessions, but it should not have been! It should not have been because I have been using the excellent jQuery library for about two or three months now, So I should have found most of this talk familiar and therefore not of that much interest.

Instead, I was really impressed with the quality of the session. John was showing the features of jQuery with code examples, and throughout his talk, people from the audience would ask if it was possible to do various things, and he was always able to answer in a polite, positive way, constantly changing his code on the fly in front of everyone. Many of the seemingly complex things that were being asked were implemented not by one line of code, but one word or two!

The talk wasn’t really about building prototypes, though, more about just using it. (And it isn’t just for prototyping; it is being used in a lot of big places.)

If you haven’t seen it, check out the jQuery site and try it out. It’s really growing on me. While I initially found it weird, it is amazingly powerful, simple, efficient and productive. Its quite different to most of the other popular JavaScript frameworks, especially in how it queries the DOM so efficiently and with hardly any code! I have removed anywhere from 40-60% of some of my JavaScript code when I have used it and I hope to use it more.

Update: Slides for the JQuery presentation are now available.

Metaprogramming JavaScript

By Dan Webb, a JavaScript expert and part of the core Prototype JavaScript framework team

I had bumped into him the day before during a session break, and he was saying he was nervous about his talk with so many experts as speakers!

But he did a great job explaining a decent topic: meta programming; programming JavaScript to augment itself at run time (e.g. to overcome deficiencies such as IE’s limited event handling in an efficient manner). Rather than describe the things he talked about, have a look at his metaprogramming slides.

Dojo 1.0: Great Experiences For Everyone

By Alex Russell, project lead for the Dojo Toolkit

Instead of talking about Dojo, Alex Russell decided to talk about the state of the web in general — which was a great talk!

Interesting points included that the emergence of Adobe’s Flex, Microsoft Silverlight, etc signaled a sign of problems for the web; that it may not be evolving much, that it may be hitting the walls of complexity.

He felt that even JSF/JSP (JavaServer Faces and JavaServer Pages) could be a sign of this pain (these technologies use a component-based approach to develop web apps, similar to ASP.NET, so I’d add that to his concern). His point was that Java developers appear to be afraid of getting their hands dirty with HTML, JavaScript etc, preferring these components to do it instead. Instead, developers do need to care about markup. These same criticisms apply, in my opinion, to ASP.NET. (During the Q & A session just after his talk, a lot of people voiced concerns about Microsoft’s dominance slowing down change.)

JavaScript: The Good Parts

By Douglas Crockford, Architect at Yahoo! Inc, a well known JavaScript guru who also came up with JSON!

Perhaps one of the two foremost people on JavaScript, this talk was interesting, because Crockford, despite his knowledge of JavaScript is known for being against the proposed ECMAScript 4 specification (which would be implemented as JavaScript 2). He feels that while the additions proposed are interesting and good, it makes the language quite different, and so should be called something other than JavaScript (else he seems to be for it, from what I can tell!).

He has written previously that, “JavaScript is a sloppy language, but inside it there is an elegant, better language”, and that was a point he was trying to make again, quite effectively, I thought.

This talk looked at a number of things problematic with the language and also what worked so well (e.g. lambda functions, closures, the functional programming aspects of JavaScript, the dynamic and flexible nature of the language, etc.)

One annoying (even dangerous) mistake with the JavaScript language he pointed out was semi-colon insertion, whereby if you omitted the “;” at the end of a statement, the parser would add it in for you. While this may have been kinda understandable at the time JavaScript came out (to help non-programmers, etc), it had an impact even on code convention:

While in other languages, coding standard/style is typically a matter of preference, here was an example where opening the curly brace on the same line is a MUST for JavaScript:

return
{
    name : value;
}

Is NOT the same as

return {
    name : value;
}

In the first example, because of semi colon insertion, the interpreter will actually do this:

return ;
{
    name : value;
}

(It will add a semi colon after return!)

Bizarre, but rests the debate on where to open your curly brace for JavaScript!!

He mentioned the tool he wrote a few years ago, JSLint, that checks your JavaScript much like Lint does for C etc (it will catch the above issue, amongst many other things!). Will be worth looking into further and possibly integrating it into our build processes (which they do with Yahoo’s YUI, for example).

He also made the controversial statement in the panel discussion that followed, that CSS was shit, which didn’t go down too well! (Though he also said he is not a designer, or something like that!)

The other concern he raised was that IE 6 in particular was holding back the advancement of JavaScript; that changes were hard to introduce because of the prevalence of this poor quality browser.

Discussion Panel

Moderated by Jeremy Keith (the guy who coined the term — and authored a popular book by the same name — “DOM Scripting”)

Brenden Eich, Stuart Langridge, Alex Russell, and Douglas Crockford were on the panel answering questions raised by the audience. Most were around JavaScript’s future, what frameworks people were using, and concerns about Microsoft’s domination of the web (its negative impact on the web developer community and whether it mattered any more or not), etc. Some good topics and debates!

Conclusion

A really good day; lots of ideas and details. Some of the powerful aspects of JavaScript were shown in simple terms.

The last @media conference got me excited enough to finally start this blog. This one gives me a sense of urgency to replace some of my JavaScript code with jQuery

This event was one of the premier JavaScript/ajax events including speakers such as Brendan Eich (Mozilla, and inventor of JavaScript), Douglas Crockford (Yahoo, and creator of JSON), Derek Featherstone (Further Ahead), John Resig (jQuery), Jeremy Keith (author of Bulletproof Ajax), and Dion Almaer & Ben Galbraith (Ajaxian).

Every session was of interest. By no means are these a complete set of notes of everything said, just an overview and my impressions of it:

Overall

Great. Good to hear from some of the key people in this field. Though the conference felt more about JavaScript than just AJAX (but that was a good thing IMO).

A number of sessions talked of how JavaScript was hated and considered too basic for serious programmers until just recently and yet, without having really changed that much over the 10 years, is now well-respected, incredibly powerful, and very misunderstood!

The State of AJAX

By the guys who run Ajaxian.

Interesting talk noting various improvements in just a few short years, and some of the innovative things that are coming, from Mozilla (Tamarin, Screaming Monkey etc), Google (Gears, GWT), various frameworks (JQuery, YUI, dojo, etc), and of trends such as AJAX on desktop apps (Adobe AIR, Slingshot, Silverlight, Prism etc).

They presented a pie chart showing almost 50% of web developer’s time was typically wasted on sorting out problems with IE/Microsoft! Made people laugh, because how true it unfortunately is. (It was interesting — though not unexpected — that in almost every session there was some note, minor or major, of how much Microsoft/IE had stagnated/held back the web.)

Google Gears’ use of worker pools and other features to improve both security and performance was mentioned, which was quite interesting. (Gears has many things being considered for HTML 5 — including the much-talked about off-line storage — but because Gears requires a separate install on the user’s browser, I hadn’t really given it much attention. I am certainly interested to learn more now.)

The other point they made was that AJAX-based apps were now raising the bar on web apps; from form to function to the “wow” factor. They mentioned an interesting usability study looking at two apps with the same functionality, except one just looked better. They asked people around the world (not just US and/or Europe) which one they thought they were more productive with. They all said the better looking one. Whether it was true or not wasn’t the point; the wow factor was.

But I’m a bloody designer!

Interface designer Mike Stenhouse provided the perspective of a designer who, being comfortable on the design/HTML/CSS end of things in the past, perhaps with simple JavaScript stuff (image rollovers etc) would leave the construction and server-side programming to others. However, with web applications much has changed. For example, more programmers are coming to JavaScript and even “taking JavaScript away from the designer.”

He talked about how he found himself being more involved in day to day discussions and decisions and that agile development was a good fit for this changing, even for a designer. He found himself being involved both as a customer representative as well as part of the team, even involved in pairing with developers (not to write code necessarily but to appreciate the coding issues and to allow developers to appreciate the design issues).

It was interesting (and good) to hear a designer talking about the merits of Test Driven Development and even Behaviour Driven Development!

Real World Accessibility for Ajax-enhanced Web Apps

By accessibility expert, Derek Featherstone.

While he covered techniques that should be reasonably well known now for people who have been following web standards etc for the last few years, he presented it really well so hopefully those not as interested or aware of the issues should be better armed now.

Fundamentally he reiterated that markup still matters; that the structure of the HTML was still fundamental and should come first.

How To Destroy The Web

By Stuart Langridge, author and one of the founders of the Web Standards Project’s DOM Scripting Task Force.

This was a funny, tongue-in-cheek, look at how not to do web development or further the web.

Planning JavaScript and Ajax for Larger Teams

By Christian Heilmann, JavaScript expert, now Yahoo! UK lead web developer, standards evangelist and trainer.

Good discussion on the importance of team development. Also made a point that front end stuff like CSS and JavaScript should be treated as application code; with a build process.

Mentioned tools like JSLint for quality, minification and consolidation for performance, all things I have been interested in looking into further.

Another decent idea around team motivation and knowledge sharing was the “lightning talks” — 5 minutes to present a problem, 5 minutes demo the solution, 5 minutes to discuss (and then share with the world, through blogs, wikis etc). We have tried hour long sessions with our teams which are really good, but when our development is fully underway, these are sometimes sacrificed, unfortunately. These shorter “lightning talks” are an interesting idea, which I hope we try out.

He also talked about architecting JavaScript (thinking of modules instead of pages, providing configuration capabilities, custom events, etc). All good stuff which I have been trying to do more of lately (not always perfectly though), so nice to see that being mentioned.

Afternoon Coffee Break

No, not a session, but a break! The reason this was useful for me was that as a work colleague and I were talking near the cookies and coffee area, Stuart Langridge came over, so I quickly told him I liked his session and we started talking about various things.

He had very briefly mentioned something called Comet which I asked if he could explain further. All he said was, “why not ask the guy who invented the term” pointing to another guy just standing right next to us, Alex Russell (one of the speakers for the second day)!

It was a great discussion on the idea behind Comet (rather than the client polling the server continuously for something, being able to push data and events from the server to the client, all while using the existing HTTP infrastructure, which is not built for this type of communication. In short it involves having a script element request a resource from the server, but the server never returning, just blocking until different messages/events/data needs pushing. Simple in idea but involves some complexities to overcome. I will be trying to look into this further.)

Ajax at Work: A Case Study

By Peter-Paul Koch (ppk), known for his useful quirksmode web site of tips and tricks and understanding browser incompatibilities.

Ironically for an ajax conference, the only session that actually looked at the technical aspects of ajax. He compared using XML, JSON, CSV, and HTML as the data being returned from an AJAX request, looking at pros and cons of each. (As expected, ultimately XML or JSON are better than CSV or HTML in most cases, but it all depends on the situation.)

Conclusion

So, all in all, a decent day, getting to hear from some well known people. Can’t say I technically learned much, but I don’t think that was the goal of the day as such; more to share ideas and connect.

Day 2 was for the more technical stuff, and had even more well known people talking.