FeatherGL

FeatherGL (GitHub: bnason / FeatherGL, License: MIT) by Brandon Nason is a new lightweight WebGL library. It includes support for camera manipulation, lights, meshes, textures, scenes, and even shaders. There’s an online example of an animated teapot with FeatherGL which covers some of the basic features.

Like many other WebGL libraries, the API is based around namespaced objects:

var view = new Feather.View(new Feather.WebGL(canvas[0]));

// Create the Vertex Array
var vertices = 
    [
        [0, 0, 0], 
        [1, 0, 0],
        [-Math.cos(Math.PI*2/3), Math.sin(Math.PI*2/3), 0],
    ];
// Create the Vertex Index Array
var vertexIndexArray = [ 0, 1, 2 ];

// Create the Normals Array
var normals =
    [
        [0, 0, -1],
        [0, 0, -1],
        [0, 0, -1],
    ];

// Construct an RGBA color
var colors =
    [
        [1.0, 0.0, 0.0, 1.0],
        [0.0, 1.0, 0.0, 1.0],
        [0.0, 0.0, 1.0, 1.0],
    ];
var triangle = new Feather.Mesh(vertices, vertexIndexArray, normals, colors, Feather.MESH_TRIANGLE_STRIP);

TunnelGL

TunnelGL (GitHub: jeromeetienne / tunnelgl) by Jerome Etienne is a small WebGL demo that looks like a demoscene tunnel effect straight out of the 90s. I suspect it’s going to form a tutorial on the author’s blog, Learning Three.js, but I’m including it here purely because I love tunnel effects.

Actually, it’s a good example of a project that uses Boilerplate for three.js, another one of Jerome’s projects.

Gitview

A reader sent in Gitview (GitHub: bouchon / Gitview, License: WTFPL) by Paul Bouchon is a widget that displays GitHub repository information. It can be used as a jQuery plugin, but is also framework agnostic:

var view = new Gitview({ 
  user    : 'bouchon',      // any github username
  domNode : document.body,  // domNode to attach to
  count   : 2,              // (optional) number of repos per widget page
  width   : '450px',        // (optional) width of widget
  compact : false,          // (optional) compact mode or full mode?
  noFrame : false,          // (optional) no fancy widget frame, just repositories
});

All that’s required to use Gitview on a page is the addition of the Gitview.js, which the author has hosted at http://logicalcognition.com/Projects/Gitview/Gitview.js.

Last week I started retrofitting Turing with AMD (Asynchronous Module Definition) support. This week I’ll complete most of this conversion to AMD by demonstrating how to use AMD modules both with and without a script loader.

Backwards Compatibility

James Burke, creator of RequireJS, contributed to Dojo’s script loader. As we’ve seen previously in this series, Dojo ships with a resource loader that’s capable of loading AMD modules, and is in fact built upon AMD. In contrast, jQuery conditionally supports AMD if a define function exists.

I wanted to do something slightly different: use define to express module dependencies, but still allow people to include Turing modules on a page without using a script loader. All modules are dependent on turing.core, and some are dependent on the dom and events modules. Turing contains some useful Underscore-like functionality in the turing.enumerable module, and I’ve always avoided reusing it in other modules because there wasn’t a way of expressing the dependency.

Therefore, I want Turing to be structured using AMD and to support these use cases:

• Load modules with script tags
• Use a monolithic, optionally minimised, build of the entire framework
• Load Turing modules with a script loader

This means we need an alternative method to jQuery’s conditional AMD support. Dojo’s built-in script loader is another solution, but it’s actually a huge amount of work and people might not always want to use a script loader.

So, what do we do? There are a few ways to approach this problem:

1. Make the build process change calls to define to work without a script loader
2. Force people to use a script loader
3. Patch define when not available

The first option seems like it would require too much maintenance – people would have to choose an AMD Turing download or a non-AMD version. The second option allows us to build Turing using AMD’s nice, modular structure, but completely breaks backwards compatibility. The third option has potential, and this is the one I spent some time exploring.

Patching define

To support AMD’s define method when an AMD-compatible script loader isn’t available, I added a method to turing.core:

// turing.core.js
(function(global) {
  var turing = {}, modules = {};

  // `turing.core`'s code goes here

  turing.define = function(module, dependencies, fn) {
    if (typeof define === 'function' && define.amd) {
      define(module, dependencies, fn);
    } else {
      if (dependencies && dependencies.length) {
        for (var i = 0; i < dependencies.length; i++) {
          dependencies[i] = modules[dependencies[i]];
        }
      }
      modules[module] = fn.apply(this, dependencies || []);
    }
  };

  // Export `define``
  if (typeof define === 'undefined') {
    global.define = turing.define;
  }
}(typeof window === 'undefined' ? this : window));

// turing.dom.js
define('turing.dom', ['turing.core'], function(turing) {
  // `turing.dom` source
});

By wrapping each module in a define statement, individual modules can now be loaded using RequireJS, and they’ll automatically load turing.core:

require(['turing.anim'], function(anim) {
  turing('#results').html('Turing has loaded with the DOM module.');
  turing.anim.chain(turing('#animate')[0]).move(1000, { x: '100px', y: '100px', easing: 'ease-in-out' });
});

The turing function here is the global turing method that will get exported to window. The turing.anim module has turing.core as a dependency, so we get the familiar turing function as expected.

This snippet is used by a functional test that I wrote to ensure Turing modules can be loaded with RequireJS. It’s a small Express app that can be found in test/functional/require.js.

Conclusion

jQuery is currently a monolithic framework (although the build process can be customised to remove unwanted libraries) which makes supporting AMD relatively easy. Conversely, Dojo is highly modular – it’s built on AMD and includes its own module loader.

Here I’ve presented an alternative solution that uses a lightweight version of AMD’s define method to support module loading through script tags, monolithic files, and AMD-compatible script loaders. It’s a potentially useful pattern for structuring large libraries and frameworks that have interdependent modules.

The code for this tutorial can be found in commit 4361042.

i18next

i18next (GitHub: jamuhl / i18next-node, License: MIT, npm: i18next) by Jan Mühlemann is a library for supporting multiple languages in Node applications. I previously posted about i18next in the jQuery Roundup.

i18next supports the expected set of translation tools, like pluralized strings, variables, and nesting. This Node port adds much-welcomed features like Express middleware and template support.

To add the required helpers to an Express app, call i18next.registerAppHelper(app), then use a familiar t() function to access translations in templates. The author provides a Jade example, so fans of the authentic TJ Holowaychuk Express/Jade/Stylus stack should be happy.

Sift.js

sift.js (npm: sift) by Craig Condon is a MongoDB-inspired array filtering library. It’s a bit like an alternative to Underscore for people who love MongoDB. Sift.js supports operators like $in and $gt, but can also filter arrays based on functions and even works with deeply-nested objects in arrays.

Craig has provided a few examples that should look familiar to Mongo users:

var sift = require('sift');

sift({ $in: ['hello','world'] }, ['hello','sifted','array!']);
// ['hello']

Full documentation is included, covering all of the supported operators and deep searching.

Comb

Comb (License: MIT, npm: comb) by Doug Martin is a framework for Node that includes “frequently needed utilities”, like logging tools, string and date formatting, flow control, and various collection algorithm implementations such as BinaryTree and PriorityQueue.

Every class provided by Comb has documentation at pollenware.github.com/comb. One of the interesting things I noticed about this project is the author claims 99% test coverage, so that fellow who filled out our JavaScript survey with “I code everything perfect on the first try” might want to check out the source.

CraftMap

CraftMap (License: free for non-commercial use, Price: $49, Size: 13KB, Minified: 6.5KB) by Marcin Dziewulski is a lightweight plugin that turns an image into a map, complete with overlays and markers.

The plugin comes with lots of options, including saving position to cookies, map positioning, and controls.

Marcin has also written a whole slew of other plugins:

• Scroller (License: free for non-commercial use, Price: $24, Size: 5KB, Minified: 2.7KB)
• CSS 3D Gallery
• Custom Preloader Effect
• Horizontal Bar Graph with CSS3

Scrollorama

Scrollorama (GitHub: johnpolacek / scrollorama, License: MIT and GPL, Size: 9.63KB) by John Polacek is a plugin for controlling animations as a page is scrolled. Once a page is split into blocks, events can be triggered as blocks become visible:

var scrollorama = $.scrollorama({
  blocks: '.scrollblock'
});

scrollorama.onBlockChange(function() {
  alert('You just scrolled to block#' + scrollorama.blockIndex);
});

Elements can be animated, like the examples on Scrollorama’s site:

scrollorama.animate('#example1', {
  duration: 400, property: 'opacity'
});

Plugins Archive

After the official jQuery plugin site was shelved, the old content has now been reinstated at archive.plugins.jquery.com.

The new site is open source and can be found at GitHub: jquery / plugins.jquery.com. It can be installed locally, and requires a web server, PHP, MySQL, WordPress, Node, and Git.

Gerbil

Gerbil (npm: gerbil) by Bruno Aguirre is a test framework for both Node and client-side development. Tests are structured in a BDD-like style, and assertions are included. It’s a small library but it offers a quick way to get started writing tests without many dependencies. I noticed that tests asynchronous code is supported because tests are run against a timeout, but there doesn’t appear to be an explicit “this test is finished” method call to directly support asynchronous code.

Tests with Gerbil look like this:

scenario('This is a group of tests', {
  'should assert true': function(g) {
    g.assert(true);
  }
});

Smoking

Smoking (npm: smoking), also by the same author, is a mocking and stubbing library. Prototype classes can be stubbed, and then expectations can be defined:

smoking(anObject).expects('aMethod');
smoking(anObject).verify();

When verify fails an exception will be raised, so this should be handled by most testing libraries.

URI.js

URI.js (GitHub: medialize / URI.js, License: MIT and GPL v3) by Rodney Rehm is a library for manipulating URIs that has a method chaining API. It makes manipulating everything from authentication details to query strings extremely easy:

URI('http://dailyjs.com/example.html')
  .directory('files')
  .hash('header')
  .query('field', 'value')
    // http://dailyjs.com/files/example.html?field=value#header

For a complete list of methods, see the URI.js API documentation.

Meincraft

Meincraft (GitHub: mitsuhiko / webgl-meincraft, License: BSD) by Armin Ronacher a WebGL demo that generates terrain and allows navigation with its own camera implementation.

It’s currently a simple personal project rather than a fully-fledged web-based Minecraft engine, similar to the three.js Minecraft demo, but it’s an interesting start and different to the other WebGL Minecraft clones that I’ve found so far.

Virtual Joystick

Let’s Make a 3D Game: Virtual Joystick by Jerome Etienne is a tutorial on his virtualjoystick.js project which provides a joystick suitable for use with touchscreens. It works a lot like the joysticks seen in many iOS and Android games.

The tutorial post includes a demo, and it even works with a mouse. The basic API is simply var joystick = new VirtualJoystick().

Filer.js

Filer.js (GitHub: ebidel / filer.js, License: Apache 2.0) by Eric Bidelman is a friendly API for the HTML5 FileSystem API based around Unix commands. Most commands are asynchronous and expect a callback:

var filer = new Filer();
filer.init({size: 1024 * 1024}, onInit.bind(filer), onError);

function onInit(fs) {
  filer.ls('/', function(entries) {
    // entries is an Array of file/directories in the root folder.
  }, onError);
}

function onError(e) { ... }

That example lists a directory. Other familiar commands include cd, create, mkdir, rm, cp, mv, open, and write. Each API method is documented in the project’s README file in the repository.

Last week I looked at how AMD (Asynchronous Module Definition) works and how projects use it. This week I’m going to show how to retrofit it to an existing project, in this case our Turing framework, and hopefully you’ll be able to apply this to your own reusable client-side JavaScript.

Redefining Modules

Turing’s modules were structured around Immediately-Invoked Function Expressions (IIFEs), with CommonJS module loading support. AMD supports CommonJS modules, and Node can work with AMD too.

The core Turing module can be defined as an AMD module like this:

define('turing.core', [], function() {
  var turing = function() {};

  // Core functionality added here

  return turing;
});

A module loader is now needed to use this code in a browser. RequireJS works like this:

require(['turing.core'], function(turing) {
});

The methods in turing.core.js will be available once RequireJS has loaded the script.

Dependencies

A good reason for using AMD is dependencies can be specified and resolved by loaders. In Turing, every module depends on turing.core. That means the DOM module would have to be updated to look like this:

define('turing.dom', ['turing.core'], function(turing) {
  var dom = {};
  // DOM module defined here
  return dom;
});

Previously, expressing dependencies between modules wasn’t possible outside of code comments. Dependencies make it easier to break down functionality into smaller reusable chunks and loaded when required.

 Loading the Entire Framework at Once

When using frameworks like jQuery, many projects need a broad selection of functionality and therefore load the entire library rather than parts of it. Rather than forcing users to use require or define invocations with a large amount of dependencies, it’s possible to offer a broad selection in one file.

I’ve created a turing.js file that contains the following:

define('turing', ['turing.core', 'turing.dom', 'turing.anim'], function(core, dom, anim) {
  core.dom = dom;
  core.anim = anim;
  return core;
});

These are the modules that I’ve ported to work with AMD so far, but I’ll add all of them under turing.js once I’ve finished.

Building

What about building a monolithic, minified version of Turing? RequireJS addresses this by including the RequireJS Optimizer. This basically boils down to:

> npm install requirejs
> r.js -o app.build.js

Conclusion

I’ve started adapting Turing to work with AMD, and my early tests work with RequireJS. However, I’m finding it difficult to get builds to generate with r.js (it seems like the current release has bugs).

Although using AMD’s well-defined module pattern and dependencies solves certain problems when developing reusable code, it makes it difficult to satisfy users who simply want to include a library using a script tag without a module loader like RequireJS. I’ve been experimenting with creating a small define function that is used when a module loader isn’t available, and I’ll cover that in next week’s tutorial.

Clarinet

Clarinet (GitHub: dscape / clarinet, License: Apache 2.0/MIT, npm: clarinet) by Nuno Job is a streaming JSON parser. The parser is event-based, and since it’s streaming it makes dealing with huge files possible. The author still recommends using JSON.parse for most tasks, however.

The announcement blog post linked to above has detailed performance analysis and more background on the project.

Sandbox

Sandbox (GitHub: gf3 / sandbox, npm: sandbox) by Gianni Chiappetta is a sandbox for Node. That means untrusted code can be run in a relatively safe environment. It comes with some useful features, including timeouts and error handling.

To execute code in a sandbox, the run method on a Sandbox instance must be used:

var s = new Sandbox()
s.run( '1 + 1 + " apples"', function( output ) {
  // output.result == "2 apples"
})

actionHero

actionHero (License: license.txt, npm: actionHero) by Evan Tahler is a transactional API framework for sockets and HTTP clients. Actions are defined for GET and POST requests, and they’re constructed from simple objects decorated with metadata for documentation:

var action = {};
action.name = "randomNumber";

action.description = "I am an API method which will generate a random number";
action.inputs = {
  "required" : [],
  "optional" : []
};
action.outputExample = {
  randomNumber: 123
}

action.run = function(api, connection, next){
  connection.response.randomNumber = Math.random();
  next(connection, true);
};

exports.action = action;

The framework comes with MySQL support, Models are implemented using the Sequelize MySQL ORM library.

actionHero also supports “tasks”, which are periodic actions performed by the server. Other features and example code can be found in the project’s repository.

jQuery-inlog

jQuery-inlog (GitHub: Prinzhorn / jquery-inlog, License: MIT) by Alexander Prinzhorn is a passive plugin that injects console.log calls into jQuery core. It can help debug selectors and chained calls.

This plugin has several options that can be changed at any time:

$.inlog({
  enabled: false,    // Shortcut: $.inlog(true|false);
  thisValue: false,  // Output this-value or not
  returnValue: true, // Output return-value or not
  indent: true       // Indent nested calls or not
});

-prefix-free

-prefix-free (GitHub: LeaVerou / prefixfree, License: MIT) by Lea Verou makes it possible to use CSS properties without vendor strings, adding the required prefixes only when they’re required. Every stylesheet in <link> or <style> tags will be processed, and jQuery’s $.css() method can be used to get or set CSS properties without prefixes.

The browsers supported are IE9+, Opera 10+, Firefox 3.5+, Safari 4+ and Chrome:

In older browsers like IE8, nothing will break, just properties won’t get prefixed. Which wouldn’t be useful anyway as IE8 doesn’t support much CSS3.

There are a few limitations that the author has documented on the project’s site: @import stylesheets aren’t supported, and neither are cross-origin stylesheets.

The jQuery plugin part of -prefix-free is here: prefixfree.jquery.js. This plugin adds the required changes to allow $.css() to work transparently.

jquery.animate-enhanced

jquery.animate-enhanced (GitHub: benbarnett / jQuery-Animate-Enhanced, License: MIT) by Ben Barnett is an increasingly popular plugin for extending $.animate() to detect CSS transitions for modern browsers. It’s tested with jQuery 1.3.2 to 1.6.1 and is even compatible with IE6+.

The plugin will analyse the properties you’re animating on, and select the most appropriate method for the browser in use. This means your transitions on left, top and opacity will convert to a CSS3 transition on Webkit & Mozilla agents that support it, and Opera 10.50+. If the user is on a browser that has no CSS3 transitions, this plugin knows about it and won’t get involved.

By including this plugin on a page, jQuery animations should use CSS3 translate where available. Outside of this basic usage, there are also three new options for $.animate():

• avoidTransforms: Avoid using -webkit-transform or similar to aid hardware acceleration
• useTranslate3d: Use 3D translations, the author recommends this for iPhone-focused development
• leaveTransforms: Once transitions are complete, remove them and convert positional values back to the real values

3D support is enabled by default, and can be toggled by using $.toggle3DByDefault().

Backbone Fundamentals

Backbone Fundamentals (GitHub addyosmani / backbone-fundamentals) by Addy Osmani is a new book that introduces Backbone to beginners, helping to piece together the collection of tools and knowledge required to use it effectively.

It’s still being worked on, but Addy has already written a huge amount that can be read in the GitHub repository’s Backbone.js Fundamentals README.md file.

There’s also a Backbone Fundamentals wishlist for those wishing to add their own suggestions for the book, or perhaps even help through contributions.

Boilerplate for Three.js

Boilerplate for Three.js (GitHub jeromeetienne / threejsboilerplate) by Jerome Etienne is a template to get started with three.js development.

It renders WebGL if available, else it’ll fall back to a 2D Canvas. It’ll also create a scene with camera controls, touch event support, fullscreen, window resize, and screenshots.

 zoom.js

zoom.js (GitHub: hakimel / zoom.js) by Hakim El Hattab is a small JavaScript API for zooming into a specific point on a page or a DOM element. The author states that it’s an experimental proof-of-concept, but the effect worked well on the browsers I tested it with.

Some browsers will have a more noticeable visual glitch as anti-aliasing is applied, but the effect uses animation easing so it feels relatively gentle considering what’s actually happening behind the scenes.

randexp.js

randexp.js (GitHub: fent / randexp.js, License: MIT, npm: randexp) by Roly Fentanes is a library for creating random strings based on a regular expression. The resulting string will match the expression provided:

require('randexp');
/hello+ (world|to you)/.gen
// => hellooooooooooooooooooo world

A more useful example might be generating a random date:

new RegExp((January|February|March|April|May|June|July|August|September|October|November|December) ([1-9]|[12][0-9]|3[01]), (19|20)[0-9][0-9]).gen
// March 4, 2038

This could be a useful way to generate test data in unit tests.

The way the RegExp object is modified by this library goes against the grain a little bit, and using a getter to return values seems a little bit odd, so I’ve asked the author about the API design through GitHub.

ECMAScript 5 Presentation

I don’t usually post slides, because without the corresponding talk they’re usually too hard to follow. ECMAScript 5 by Damian Wielgosik is a 150 slide presentation that introduces ECMAScript 5, and is relatively easy to follow if you don’t mind pressing the right arrow key 150 times.

The majority of the slides are concerned with new methods on Object, and some patterns that make use of these new methods are explained. Other areas covered include Function.prototype.bind, new Array.prototype methods, and strict mode.

Particles: Online Editor for Sparks.js

Particles: Online Editor for Sparks.js is an introductory tutorial for sparkseditor (GitHub: jeromeetienne / sparkseditor, License: MIT) by Jerome Etienne which is a GUI editor for Sparks.js, a 3D JavaScript particle engine.

Press the “code” button to show the code used to generate the particle system. The code can be edited, and the changes will be displayed in real time. To share the results, press the “export” button.

A wide range of effects can be created with Sparks.js. There are examples available at jabtunes.com/labs/arabesque/.

In Improving Client-Side Modularity I talked about better ways to load modules, and showed how jQuery supports the Asynchronous Module Definition API. As open source developers, supporting this specification makes it easier for others to reuse our code. It also helps resource loading frameworks like RequireJS.

In the Let’s Make a Framework series, we’ve already covered Common JS Modules and seen how they can make our code accessible for Node developers. However, implementing a convincing client-side version of this is difficult because require is generally implemented as a synchronous statement. There are projects to wrap this for browser-based development, but AMD offers a native solution that’s easy to work with. This is where AMD steps in as a “transport format”.

Conditional AMD Support

jQuery provides conditional AMD support. When writing smaller, tightly focused libraries, this is a useful approach because it allows AMD to be supported where available. jQuery checks for the existence of define, and this approach can be reused:

var myModule = {
  awesome: 'not really'
};

if (typeof define === 'function' && define.amd) {
  define('myModule', [], function() {
    return myModule;
  });
}

The amd property is explained by the AMD specification:

To allow a clear indicator that a global define function (as needed for script src browser loading) conforms to the AMD API, any global define function SHOULD have a property called “amd” whose value is an object. This helps avoid conflict with any other existing JavaScript code that could have defined a define() function that does not conform to the AMD API.

We need to check for both the define function, and that it conforms to the specification.

Internal AMD Use

Another approach is to build an entire project around AMD. Dojo was restructured to work this way. This comment is from Dojo’s source:

This function defines an AMD-compliant loader that can be configured to operate in either synchronous or asynchronous modes.

Then modules are wrapped with define:

define(["./_base/kernel", "./_base/lang", "./_base/Color", "./_base/array"], function(dojo, lang, Color, ArrayUtil) {

});

Notice how dependencies in AMD are the same order as the callback (or “factory function”, as the AMD specification refers to it). This is explained in the specification:

[…] the resolved values should be passed as arguments to the factory function with argument positions corresponding to indexes in the dependencies array.

As I mentioned in Improving Client-Side Modularity, Kris Zyp documented this move to AMD in Asynchronous Modules Come to Dojo 1.6.

CommonJS Wrapping

The AMD specification also addresses CommonJS modules with this example:

define(function(require, exports, module) {
  var a = require('a'),
      b = require('b');

  exports.action = function() {};
});

The RequireJS documentation points out that this can help with cases where there are a lot of dependencies:

define([ 'require', 'jquery', 'blade/object', 'blade/fn', 'rdapi',
         'oauth', 'blade/jig', 'blade/url', 'dispatch', 'accounts',
         'storage', 'services', 'widgets/AccountPanel', 'widgets/TabButton',
         'widgets/AddAccount', 'less', 'osTheme', 'jquery-ui-1.8.7.min',
         'jquery.textOverflow'], // ...

This is difficult to read. The RequireJS documentation goes on to say that using require is potentially easier to follow. An AMD module loader has to parse out the require calls and insert the define dependencies transparently.

Since the authors of RequireJS have experience implementing such things, they’re all too aware of browser inconsistencies and limitations:

Not all browsers give a usable Function.prototype.toString() results. As of October 2011, the PS 3 and older Opera Mobile browsers do not. Those browsers are more likely to need an optimized build of the modules for network/device limitations, so just do a build with an optimizer that knows how to convert these files to the normalized dependency array form, like the RequireJS optimizer.

This means a pre-compilation step may be necessary to support a broad range of browsers using this approach.

Conclusion

If you’ve followed our previous tutorials on building an asynchronous script loader, you’ll know that writing JavaScript APIs for loading scripts isn’t trivial. Supporting CommonJS isn’t necessarily difficult, but supporting features like parsing require calls is where things get tricky.

This leads us to an important point that must be considered when building our own libraries and frameworks: should we ship our own script loading solution, or conditionally support AMD? Given the complexity of building a script loader, it may be better to conditionally support AMD as jQuery does.

This doesn’t quite satisfy our needs for Turing, however. Turing does have one or two modules that are dependent on each other, and define provides a way to express this programatically. It may be better to use define to wrap modules, as we already do using an IIFE (Immediately-Invoked Function Expression), and effectively no-op it if it isn’t present.

Next week I’ll look at adding AMD to Turing, then test it out with RequireJS.

References

• Asynchronous Modules Come to Dojo 1.6
• Improving Client-Side Modularity
• RequireJS: Why AMD?
• AMD Wiki
• CommonJS Modules

Node 0.6.6

Node 0.6.6 is out, which updates npm, fixes some bugs, and adds pause/resume semantics to stdin. Node also has a new website that is greener than ever, but remains clean and features a new corporate-friendly edge.

There’s also a post on the official Node blog entitled Growing up by Ryan Dahl that discusses Windows Azure support:

The overarching goal of the port was to expand our user base to the largest number of developers. Happily, this has paid off in the form of being a first class citizen on Azure.

asyncblock

asyncblock (License: MIT, npm: asyncblock) is a fork of node-green-light. It works like a flow control library combined with node-fibers.

The author compares a ‘pure Node’ example with his own library’s code:

function example(callback){
    var finishedCount = 0;
    var fileContents = [];

    var continuation = function(){
        if(finishedCount < 2){
            return;
        }

        fs.writeFile('path3', fileContents[0], function(err) {
            if(err) {
                throw new Error(err);
            }

            fs.readFile('path3', 'utf8', function(err, data){ 
                console.log(data);
                console.log('all done');
            });
        });
    };

    fs.readFile('path1', 'utf8', function(err, data) {
        if(err) {
            throw new Error(err);
        }

        fnishedCount++;
        fileContents[0] = data;

        continuation();
    });

    fs.readFile('path2', 'utf8', function(err, data) {
        if(err) {
            throw new Error(err);
        }

        fnishedCount++;
        fileContents[1] = data;

        continuation();
    });
}

This is the equivalent source using asyncblock and fibers:

var asyncblock = require('asyncblock');

asyncblock(function(flow){
    fs.readFile('path1', 'utf8', flow.add('first'));
    fs.readFile('path2', 'utf8', flow.add('second'));

    var fileContents = flow.wait();

    fs.writeFile('path3', fileContents.first, flow.add());
    flow.wait();

    fs.readFile('path3', 'utf8', flow.add());
    var data = flow.wait();

    console.log(data);
    console.log('all done');
});

Error handling is addressed by including flow.errorCallback. There are examples of how to use this in the project’s documentation.

Introduction to Node Modules

Robert Kuzelj has been writing a series of posts about Node modules:

• Introduction to Node Modules Part 1
• Introduction to Node Modules Part 2
• Introduction to Node Modules Part 3

He demonstrates how to make packages, and how to take advantage of npm’s major features.

Review19

In other Node-related DailyJS articles I’ve invited readers to share their own apps with the community. Review19 by Srirangan is one such project: a kanban and scrum project management tool.

It’s built with Socket.IO to provide a real-time view of a project, and uses simple agile-inspired records that should be familiar to users of Jira or Pivotal Tracker.

Sign up is free, so give it a try. The author has a Google Group to support the community at Review19 Community.

AMD-Utils

AMD-Utils (GitHub: millermedeiros / amd-utils, License: MIT) by Miller Medeiros is a set of modular utilities written using the AMD API.

All code is library agnostic and consist mostly of helper methods that aren’t directly related with the DOM, the purpose of this library isn’t to replace Dojo, jQuery, YUI, Mootools, etc, but to provide modular solutions for common problems that aren’t solved by most of them.

The modules written so far include some of the things covered on my Let’s Make a Framework tutorial series, like a functional style Array module, and other commonly required number and string utility functions often added by large frameworks.

jquery.mentionsInput

jquery.mentionsInput (GitHub: podio / jquery-mentions-input, License: MIT) by Kenneth Auchenberg and the Podio Dev Team is a UI component for handling @mentions. It’ll display an autocomplete list for matching names and allow one to be selected. Once a name is selected, it’ll change colour in the text box, as shown above.

The authors have packaged it with CSS, so it’s easy to get started right away. It does expect some data, rather than automatically searching an API like Twitter’s, so the expected format looks like this:

$('textarea.mention').mentionsInput({
  onDataRequest:function (mode, query, callback) {
    var data = [
      { id:1, name:'Kenneth Auchenberg', 'avatar':'http://cdn0.4dots.com/i/customavatars/avatar7112_1.gif', 'type':'contact' },
      { id:2, name:'Jon Froda', 'avatar':'http://cdn0.4dots.com/i/customavatars/avatar7112_1.gif', 'type':'contact' },
      { id:3, name:'Anders Pollas', 'avatar':'http://cdn0.4dots.com/i/customavatars/avatar7112_1.gif', 'type':'contact' },
      { id:4, name:'Kasper Hulthin', 'avatar':'http://cdn0.4dots.com/i/customavatars/avatar7112_1.gif', 'type':'contact' },
      { id:5, name:'Andreas Haugstrup', 'avatar':'http://cdn0.4dots.com/i/customavatars/avatar7112_1.gif', 'type':'contact' },
      { id:6, name:'Pete Lacey', 'avatar':'http://cdn0.4dots.com/i/customavatars/avatar7112_1.gif', 'type':'contact' }
    ];

    data = _.filter(data, function(item) { return item.name.toLowerCase().indexOf(query.toLowerCase()) > -1 });

    callback.call(this, data);
  }
});

Echo Nest API Plugin

Echonest-jQuery-Plugin by Samuel Richardson is a plugin for The Echo Nest which is a real-time API for accessing music data. Song data and audio fingerprinting are just some of the cool things that this API provides.

Let’s say I needed to get a set of album images. All I’d have to do is this:

var echonest = new EchoNest('YOUR_API_KEY');
echonest.artist('Radiohead').images(function(imageCollection) {
  $('body').prepend(imageCollection.to_html('<img src="${url}">'));
});

Combined with a templating system, this makes working with music data extremely convenient. The only issue with this approach is the API key is exposed. Echo Nest uses the API key for enforcing rate limits, so it’s not safe to expose it publicly. As it stands, I’d probably use client-side Echo Nest API code as a way of rapidly prototyping a music service built on this platform, then create my own server-side bridge to obscure the API key.

i18next

i18next (GitHub: jamuhl / i18next, License: MIT) by Jan Mühlemann is a client-side translation plugin with lots of features, including: plurals, localStorage, namespaces, and variables. JSON resource files can be used to store translations, and then i18next will load them as required.

Given a suitable file at /locales/en-US/translation.json:

{
  "app": {
    "name": "i18n"
  },
  "creator": {
    "firstname": "Jan",
    "lastname": "Mühlemann"
  }
}

Then $.i18n.init can be used to load the resource and access translations:

$.i18n.init({}, function(t) { // will init i18n with default settings and set language from navigator
  var appName = t('app.name'); // -> i18n
  var creator = t('creator.firstname') + ' ' + t('creator.lastname'); // -> Jan Mühlemann
});

The i18next documentation contains more examples and shows how to change languages, organise translations with nesting, and use variables.

SilkJS is a very fast JavaScript based HTTP server that was designed to work with ExtJS. All code for the server is written in JavaScript, including almost the entirety of the server itself. You can check out the server’s GitHub repository at mschwartz / SilkJS and the repository for this demo at mschwartz / SilkJS-ext.

The SilkJS Install.js script creates a /usr/share/SilkJS directory with the HTTP server, library files, and default documentRoot. It also installs the main HTTP server in /usr/local/bin/httpd-silk.js.

Let’s examine the SilkJS-ext repository first. This is config.js:

Config.mysql = {
  host: 'localhost',
  user: 'mschwartz',
  passwd: '',
  db: 'ext3'
};
Config.documentRoot = 'docroot';

This file overrides the default Config object, specifying MySQL connection information, and a documentRoot for this example.

The actual Server-Side JavaScript code is implemented in under 60 lines of code, in Server.js:

SQL = new MySQL();
SQL.connect();

Schema.add({
  name: 'Users',
  fields: [
    { name: 'userId', type: 'int', autoIncrement: true, defaultValue: 0 },
    { name: 'username', type: 'varchar', size: 64, header: 'User Name', width: 128, autoExpand: true, editable: true },
    { name: 'password', type: 'varchar', size: 64, header: 'Password', serverOnly: true, editable: true },
    { name: 'email', type: 'varchar', size: 128, header: 'E-Mail Address', width: 128, editable: true },
    { name: 'created', type: 'int', defaultValue: function() { return parseInt(new Date().getTime() / 1000, 10); }, header: 'Created', width: 150, format: 'DateTime', editable: false }
  ],
  primaryKey: 'userId',
  indexes: [
    'username',
    'email'
  ]
});


function main_action() {
  res.write([
    '<!doctype html>',
    '<html>',
    ' <head>',
    '   <title>Schema / ExtJS Demo</title>',
    '   <link rel="stylesheet" type="text/css" href="/ext-3.4.0/resources/css/ext-all.css" />',
    ' </head>',
    ' <body>',
    ' <script type="text/javascript" src="/ext-3.4.0/adapter/ext/ext-base.js"></script>',
    ' <script type="text/javascript" src="/ext-3.4.0/ext-all-debug.js"></script>',
    ' <script type="text/javascript" src="/client/Ext.ux.SchemaGrid.js"></script>',
    ' <script type="text/javascript" src="/client/ViewPort.js"></script>',
    ' <script type="text/javascript">',
    '   Schemas = ' + Json.encode(Schema.getSchemaExtJs()) + ';',
    ' </script>',
    ' </body>',
    '</html>'
  ].join('\n'));
  res.stop();
}
function Server_action() {
  switch (req.data.method) {
    case 'listUsers':
      Json.success(Schema.list('Users', {}, function(o) {
        o = Schema.clean(o);
      }));
    case 'editUser':
      var example = Json.decode(req.data.example);
      example.userId = example.userId || 0;
      Schema.putOne('Users', example);
      Json.success();
    case 'deleteUsers':
      var examples = Json.decode(req.data.examples);
      forEach(examples, function(example) {
        Schema.remove('Users',example);
      });
      Json.success();
  }
}

The first thing it does is create a global MySQL object, named SQL. This SQL object is used by the ORM to generate queries. With the ORM, you rarely have to generate any queries yourself, and even then, the ORM does most of the work.

The Schema.add() method is called to install a “Schema” in the ORM. The Schema is defined as a JavaScript object. The definition above shows only a part of what’s possible. The name member is the name of the table in the database. The fields array is an array of field definitions. The primaryKey member is the primary key of the table, and the indexes array is an array of additional indexes to be created for the table.

For the fields array, each item is an object with a few required members and some optional ones. The required ones are name, and type. If type is 'varchar', then size is also required. Only one of the fields may be autoIncrement: true, and is typically the primaryKey of the table as well. This autoIncrement field is also typically the ID field of ExtJS DataStores on the client-side.

The defaultValue member may be an expression or a function. The defaultValue member is used to set a default value for the field when creating a new entry in the database. As you can see in the example above, we have a ‘created’ field of type 'int' (a Unix-style timestamp) that has a defaultValue of a function that creates a Unix timestamp for the current time.

One additional members may be specified. Note the password field is marked serverOnly: true – this is to specify that the value of this field should not be sent to the client (we’ll see this later).

Currently, every other member of a field definition is ignored by the ORM, and can be used for your application for whatever purposes you like. In this case, I specify information that will help us generate ExtJS Grid columns, and form fields for editing records. For example, username is autoExpand: true, and fields with header: 'some string' will show in the grids.

The SilkJS HTTP server will call main_action() (if it is defined) if / is the specified URL. Here we simply write a typical HTML document to the browser. The output HTML looks like this:

<!doctype html>
<html>
  <head>
    <title>Schema / ExtJS Demo</title>
    <link rel="stylesheet" type="text/css" href="/ext-3.4.0/resources/css/ext-all.css" />
  </head>
  <body>
    <script type="text/javascript" src="/ext-3.4.0/adapter/ext/ext-base.js"></script>
    <script type="text/javascript" src="/ext-3.4.0/ext-all-debug.js"></script>
    <script type="text/javascript" src="/client/Ext.ux.SchemaGrid.js"></script>
    <script type="text/javascript" src="/client/ViewPort.js"></script>
    <script type="text/javascript">
    Schemas = {"Users":{"name":"Users","fields":[{"name":"userId","type":"int","autoIncrement":true,"defaultValue":0},{"name":"username","size":64,"header":"User Name","width":128,"autoExpand":true,"editable":true},{"name":"password","size":64,"header":"Password","serverOnly":true,"editable":true},{"name":"email","size":128,"header":"E-Mail Address","width":128,"editable":true},{"name":"created","type":"int","header":"Created","width":150,"format":"DateTime","editable":false}],"primaryKey":"userId"}};
    </script>
  </body>
</html>

All records in SilkJS and ExtJS are effectively just JavaScript objects; each member is a column/value pair from the database. But not every field from the database must exist in these objects! A partial record of this form is what I call an “example.” If you call Schema.find(example), it will do a SELECT query based upon the fields you do specify in the example. For example, Schema.find({ username: '%msch%' }) will return an array of records from the database that have a username with ‘msch’ somewhere in it. Schema.putOne({ username: 'mschwartz' }) will store a new record in the database with defaultValues for the other fields and username set to ‘mschwartz’. The only way I can explain examples is with examples!

So editUser expects the client to build an example and send it over. If editing an existing record, the example will have a userId, and the record will be updated by Schema.putOne(). If adding a new record, the example will have no userId or a userId set to 0.

The deleteUsers method expects an array of examples. It calls Schema.remove(example) on each element of the array, which deletes the specified rows from the database. Schema.remove() can be dangerous if you’re not careful about the examples you give it. In this case, the array of examples would be some multiple selections on the grid on the client side.

The client-side ExtJS code is in docroot/client and accessed via /client/whatever paths in the HTML. In this case, we have just two files, Viewport.js and Ext.ux.SchemaGrid.js.

ViewPort.js is rather simple:

Ext.onReady(function() {
  var items = [];
  for (var i in Schemas) {
    var schema = Schemas[i];
    items.push({
      xtype: 'ext-ux-schemagrid',
      title: i,
      schema: schema,
      method: 'list'+i
    });
  }


  new Ext.Viewport({
    layout: 'fit',
    items: [
      {
        xtype: 'tabpanel',
        activeTab: 0,
        items: items
      }
    ]
  })
});

It loops through the global Schemas and creates an items array of Panel configs, one Schema Grid per panel. The Ext.ViewPort is simply an Ext.TabPanel with one tab per panel.

The real work on the client is done by Ext.ux.SchemaGrid.js.

I don’t want to go into great detail about how this custom component works, but I will explain some of the things it does. Basic ExtJS knowledge is assumed here.

SchemaGrid extends Ext.grid.GridPanel and takes as additional configuration options a Schema, and a method. Those are set in the ViewPort.js code.

In the initComponent method, the URL of the JsonStore is set to /Server (so Server_action() is called on the SilkJS side), and baseParams method is set to the SchemaGrid’s config.method, listUsers in our case. The JsonStore’s fields are directly used from the Schema’s fields array (no muss, no fuss).

After setting up the SelectionModel, the code loops through the Schema’s fields and generates column definitions for the grid. Those fields that have a header member and are not serverOnly will have columns displayed. The renderer for each column is a single method in the SchemaGrid class. The default action for our renderer is to render the created/timestamp in human readable format. An autoExpand column may be specified in the Schema definition, and it is handled automatically by this code.

When the JsonStore is loaded or the user clicks on items in the grid, the updateToolbar() method is called to conditionally enable and disable the edit and delete buttons. Basically, you can only edit if one row is selected, and you can’t delete unless at least one row is selected.

The editRecord() method dynamically creates a form in a modal dialog window. If a record is passed in, the dialog title says “Edit record” otherwise “Add record.” The dialog/form can be used to add new records (click the add button) or edit existing records (select a record, click edit button).

When the OK button is clicked on the dialog, the record (EXAMPLE) is updated with the form fields’ values and the Ext.Ajax.request() made to call editUser to update the database.

The deleteRecords() method is called to delete one or more selected records in the grid. It creates the array of examples and calls Ext.Ajax.request() to invoke deleteUsers on the server side.

So let’s see it in action!

Screenshots

This is the application when it first starts:

Now the add button has been clicked:

Here I’ve added a few records:

This is what happens when a record is opened for editing:

Advantages

So, what’s neat about this?

If you edit the Schema definition at the top of Server.js, those changes will immediately be reflected in the database when you either restart the server or the browser makes a new request (reload the browser, click the reload button in the paging toolbar).

What do I mean? If you change the size of password field to 128, the ORM will submit the appropriate ALTER TABLE statements to MySQL to change the size of the field. If you add a field to the fields array, it will be added to the table in the database as well. If you delete a field, it will be deleted in the database. If you rename a field, it will be renamed in the database.

If you add a second Schema definition at the top of Server.js, the table will be created next access. If you reload your browser, you will see two tabs, one for each table, and the CRUD operations apply to both.

Outside of the Schema definitions, which are compact in their own right, and the main_action() method that spews out the HTML for the app, the entire CRUD operations on the server side consist of under 20 lines of code.

The entire demo took me under 1 hour to create, all but 2-3 minutes was spent writing the client-side code.

Kanso Package Repository

Kanso (GitHub: kanso ) has been changed to work more like a generic build system for CouchApps. It’s more framework agnostic, and includes a package repository, which is available at kan.so/packages. From Caolan McMahon in the New Kanso release and change of direction thread:

Essentially, all you need to add to your project is a kanso.json file describing how it should be built. Once your app is in this format, it’s possible to merge it with other design docs written in the same way. Using this basic principle, we’ve developed a library of JavaScript modules, build-steps, and more, all of which can be easily shared between projects.

If you’re working with CouchDB and want a relatively easy way to run JavaScript apps, then it’s worth giving Kanso a try. The community on the Kanso Google Group is still relatively small and helpful.

Recipes with Backbone

Recipes with Backbone (price: $24) is an ebook by Nick Gauthier and Chris Strom that covers an introduction to Backbone.js, namespacing, view templates, collection views, actions, animations, non-REST models, routes, and more. The full table of contents is here: Recipes with Backbone and excerpts are available for Collection View and Changes Feed.

I haven’t yet bought a copy for review, but the sample content looks promising. If you buy it, please let everyone know what you think in the comments!

Appify UI

Appify UI by Thomas Aylott helps package web apps as Mac OS X bundles. The thing that makes it slightly special is Node apps can be bundled just as easily as anything else. There’s a Node demo app, and instructions on how to make them in the project’s documentation.

The results are in! Thanks to everyone who took part, your answers are now the property of the community.

The raw result set is here: JavaScript Developer Survey 2011, Data.
A summary of the results generated by Google Docs can be downloaded here: JavaScript Developer Survey 2011, PDF.

I got the feeling that client-side developers felt a little underrepresented by the survey, so in future I can run additional client-side, server-side, or even Node-specific surveys if enough people are interested.

The purpose of this survey is purely to gather information that will help people develop software and services for JavaScript developers. For example, if you’re looking to develop an open source project and want to see what areas are lacking, then maybe this data might be useful. Download the data, and use it!

Environment

Almost everyone who took part said they do browser development (98%). Server-side web app development is also popular, at 45%. This is up 10% from last year. I find it encouraging to see an strong interesting in Unix scripting (14%).

The preferred server-side interpreter was Node, at 71%. 12% selected Other, and there were some strongly-worded comments about including more environments. Also, clarification will be applied in future surveys to state whether the question relates to browser, server, or both, and in this case it wasn’t clear to some people.

Testing, Static Analysis, Benchmarks

58% of people don’t write tests. This is actually down from 68% last year. I appreciate that testing might seem awkward for client-side development, but it’s not uncommon to find open source client-side code bundled with tests, so I’d encourage both browser-based and server-side developers to at least write basic tests if possible.

JSLint is still the king of static analysis (67%), but Google Closure Compiler and YUI Compressor are close by at 25% and 21% respectively.

Now the shocking news: Jasmine (44%) has edged out QUnit (41%)! Vows is also doing well with 13%. Express/Mocha scored 11%, slightly ahead of Nodeunit at 8%.

Another surprising trend is YUI Compressor is beating Google’s Closure Compiler for minifying code, at 41% vs. 31%. JSMIN is down in popularity again, from 25% last year to 20% this year.

The well-known cabal of Node developers with prominent packages on NPM are known for writing benchmarks. However, this survey showed that 81% of respondents use client-side tools for debugging. I suspect the Node benchmark fetishists (and I mean that in the nicest possible way) were represented by the 20% that answered “benchmark using my own code”.

Project Discovery and Hosting

Most people find JavaScript libraries and tools through GitHub (81%). Search engines are the next most popular method (51%). NPM seemed a little bit low to me, at 20% — the website isn’t actually too bad for discovering projects, it supports keywords and has links to dependent projects. When I’m working on a Node project I often find useful libraries through search.npmjs.org.

GitHub is the champion of hosting for personal JavaScript projects (90%). Bitbucket is the second most popular at 10%. I wonder if Bitbucket will grow next year given the generous deal they have on private project hosting?

Google’s CDN is the most popular third-party hosting service (83%).

Debugging

WebKit inspector has edged out Firefox with 66%, compared to 58%. Surprisingly, 525 people (51%) use node --debug, which interested me because a lot of people ask me about Node debugging without even realising it has the --debug option.

131 people said they use the Cloud 9 IDE as part of the debugging question. I’ve tried this service out myself and it does seem like an interesting way to work on client-side code (technically any code, but the debugging for client-side code is impressive).

Languages

PHP remains the most popular language amongst our readers, with 46%, which is the same as last year. I expected (wanted) more people to be interested in Clojure (2%) or Lisp in general (2%), but Ruby, Java, Python, and C#/.Net were the other most popular languages, which is again unchanged from last year.

“Other”

I promised people in the comments that I’d mention some of the “Other” field data. This is by no means an exhaustive look at this data, but some interesting observations.

Some people said they had “no preference” when it came to interpreter. Others seemed upset that I didn’t include ‘V8’, but I meant the question to be purely about server-side JavaScript, so I should have clarified that and just included Node, Ringo, etc.

In terms of unit testing, I found the following mentioned:

• Ringo’s test module
• Sinon.JS
• Evidence.js
• Around 10 custom or homegrown unit testing frameworks
• “I must start doing this”, “I CODE EVERYTHING PERFECT ON THE FIRST TRY”

Previous Surveys

• 2009
• 2010

Node 0.6.5

Node 0.6.5 is out, which upgrades V8 to 3.6.6.11 and potentially avoids national firewall-related issues.

NodeUp

NodeUp is a podcast all about Node. In NodeUp Nine features Isaac Z. Schlueter, Matt Ranney, Dominic Tarr, and James Halliday discussing scaling, deployment, and Erlang. Other topics include migrating to Node 0.6 and hosting on Joyent with Solaris.

Subscribe with either iTunes or RSS:

• NodeUp on iTunes
• NodeUP RSS

Logme

Logme (License: MIT, npm: logme) by Veselin Todorov is a slick little logging library. Basic usage looks like this:

var logme = require('logme');
logme.critical('Error');

It has a lot of colour themes, which are set by instantiating a Logme object:

var Logme = require('logme').Logme;
  , logme = new Logme({ theme: 'smile' });

logme.error('This is now themed.');

The only thing I miss is the ability to quickly append values with spaces, like this: console.log('Value:', value);.

It’s worth remembering that console also comes with console.error, which will write to stderr.

Consolidate.js

Consolidate.js (License: MIT, npm: consolidate) by TJ Holowaychuk is a wrapper that gives template engines the same API. TJ’s documentation mentions that Express 3.x uses the signature (path[, locals], callback) for template rendering, which is the same as Consolidate.js.

This library adds a thin layer that makes it easier to switch between different template engines.

mdoc

mdoc (License: MIT, npm: mdoc) by Miller Medeiros is a markdown-based documentation generator. It’ll create HTML files for each markdown file in a directory, and a table of contents.

One of the author’s examples is unofficial Node mdoc-generated documentation. He’s only been working on it for a few weeks, yet the style of the documentation it generates is readable and suits larger projects.

Some projects benefit handcrafted documentation rather than JSDoc-style API documentation. Miller wrote a post about this topic called Inline Documentation: Why I’m Ditching it.

Firmata

Firmata (GitHub: jgautier / firmata, License: MIT, npm: firmata) by Julian Gautier is a library for interacting with Arduino boards running the firmata protocol.

If you’re a Node developer you may find this more appealing than typical Arduino code:

var firmata = require('firmata')
  , board;

board = new firmata.Board('path to usb', function() {
  // Arduino is ready to communicate
});  

Nodeflakes

Nick Payne sent in Nodeflakes (GitHub: makeusabrew / nodeflakes), a Twitter Streaming API experiment that displays CSS3 unicode snowflakes that display tweets. The architecture is actually multiprocess, using a producer/consumer architecture. The client-side code is in nodeflakes-client.

Despite appearing to be a holiday-themed gimmick, Nodeflakes is very educational. The author has written a detailed blog post about the project: Nodeflakes – real time tweet powered snowflakes.

Create

Create (GitHub: bergie / create, License: MIT) by Henri Bergius is built on jQuery UI, Backbone.js, Modernizr, and VIE. It provides a dynamic editing interface suited to browser-based HTML5 content management.

One relatively unique feature of Create is the use of RDFa annotations to mark up editable content. This reminded me of a CMS I built in the early 2000s that used XSLT to transform arbitrary data into editable data, but this seems far easier to use. To read more about the RDFa portion of this project, see VIE by the same author.

jQuery/Switch

jQuery/Switch (GitHub: rawnet / jquery-switch, License: MIT) from Rawnet is an iOS-inspired slide and toggle widget:

The plugin is accessed by using the switchify method. The HTML for this plugin can be marked up by using a select element with suitable on/off values.

The documentation for this plugin is excellent, with fully interactive examples for lots of different configuration options.

Matteo Bicocchi’s Plugins

mb.jQuery Components (License: MIT and GPL) by Matteo Bicocchi is a collection of 16 plugins focused on media and UI. There’s a tree menu, draggable windows, sliders, and even a background YouTube movie player.

All of the plugins are presented with documentation and demos.

nanoScroller.js

nanoScroller.js (GitHub: jamesflorentino / nanoScrollerJS, License: MIT) by James Florentino is a Lion-style scrollbar implementation. It requires a little bit of CSS, but usage basically boils down to this:

$('selector').nanoScroller();

The author has tested it with IE8+, Firefox, Chrome, Safari, and iOS 5. Older browsers like IE7 will degrade to the native scrollbar.

Mobi Pick

Mobi Pick (GitHub: sustainablepace / mobipick, License: MIT) by Christoph Baudson is a rather cute Android-inspired date picker. It uses the impressive XDate library, and features progressive enhancement through Modernizr.

Mobi Pick has implemented localisation through XDate’s locale support, which means a localised picker can be displayed simply by specifying a language:

page.find('selector').mobipick({
  locale: 'es'
});

jQuery Geo

jQuery Geo (GitHub: AppGeo / geo) from Applied Geographics is an open source mapping project that provides a friendly JavaScript API for services like Open Street Map, WMS and Esri ArcGIS Server.

The simplest jQuery Geo demo shows how easy it is to get started with the plugin:

$(function () {
  $('#map').geomap();
});

Centring and zooming is also easy:

$('#map').geomap({
  center: [-71.037598, 42.363281],
  zoom: 10
});

The project also includes support for geometry and user interaction with geometric objects.

Brequire

We’ve been covering asynchronous script loaders a lot recently, more by chance than design, and so Jonah Fox sent in his latest updates for Brequire. I’ve mentioned this library before on DailyJS, but the recent updates add some interesting asynchronous functionality through the optional require.async.js module:

require('./app', function(app) {
  // do stuff with app
});

Also, in commit c9aba57 the author added AMD support.

Part One: Flickr’s Asynchronous Script Loading

This is part two of Production Teardown: Flickr’s Asynchronous Script Loading. To recap, if we use an async JS loader, or even if we just put our script tags at the bottom of our pages we have a problem. There is a small window where it’s possible to interact with the page before the code has loaded.

Flickr uses something they call an actionQueue, and their code is very tight and isolated. With little modification I think we could use that exact same piece of code for other things. We are going to build a simple page to put this to the test. To start, we need to make a few changes to the original code so that we can load multiple modules instead of just one.

Note: I am using QUnit to run the tests.

Adapting actionQueue.js

The code: actionQueue.js.

I had to make a couple of changes to the stock code for the purposes of generalizing the library, and to make it more testable. First, the original module is hard to test because its state is private. I wouldn’t expect anything less, the state is only used by the actionQueue function. However, during testing we need to reset the internal state of actionQueue.

One possible way to do this is to write an actionQueue factory. This is a function that creates a brand new actionQueue every time it’s called. Then it can be assigned to A.actionQueue as required. This has a lot of advantages but seems like overkill for our requirements. An alternative solution is to simply create a new function that can reset the internal state of the module. I’ve called this function refresh_module.

for (var i in an_array) {

}

var i;
for (i in an_array) {

}

I got this wrong. As some people in the comments have pointed out the variable declaration is hoisted. I have corrected the error, and welcome any additional criticism. To be clear though, I would rather have an error in everything I have ever written, than to not write at all. We can’t walk through the world constantly second guessing everything we say, or we wouldn’t say anything. The best we can do is welcome being wrong, and fix it.

With testability improved and static analysers applied, I made one more major functional modification. When I started looking at Flickr’s code I could see that there was an internal flag called queueing. When true, which is its default, interim functions get executed. When false, nothing happens; everything just passes through to the queue_click function.

What’s curious about queueing is that it’s global. actionQueue was clearly written with the idea of multiple modules, but apparently that part ended up not being needed. When the first module gets loaded queueing is set to false. That means all queue_click calls now pass through, even for modules that haven’t yet called module_load. I have a feeling that Flickr loads all of its modules in a monolithic file. They aren’t seeing any repercussions in this code because if one module has loaded, they have all loaded. I don’t think that this will be the story for everyone who might want to use this code. So, I modified it so that each module has its own queueing state.

I’ve added the code on line 38 to set queueing to true for any new modules that get added by the register function. Then as module_loaded gets called, it will only turn queueing off for that module. You can see all my tests, and how I tested the multiple module section in actionQueue tests.

Building a Like Button

To demonstrate this code, we are going to build a simple “like” button. There will be two steps. When clicked it will change state, and then there will be an action for when the module loads. The compete example is here: actionQueue in practice.

This simple markup creates a like button with two states. The visual state is controlled by flipping a class name. Then I set up some initial code building our global container, and include the actionQueue code.

Line 20 is where we start to see how the like button is going work. This is comprised of two steps. In the interim step the like button will get a new class. This will flip the visual state. In the cleanup state, which will fire after the module, like-handler loads and the like button is set to Done!.

The like button itself is implemented as HTML. It’s important to note that the anchor tag has an onclick. I know, this looks dirty, but really it’s the easiest way to handle events before all of the code has loaded. The arguments behind this were covered in the previous tutorial. So, when a user clicks the like button an event gets fired into the action queue which will first fire the interim step.

Later I setup a link that will ‘load’ the module. This will then fire the cleanup function.

Conclusion

By first researching Flickr’s code, then adapting it to be easier to test, we’ve created something genuinely useful and reusable. And although using onclick might be a little bit controversial, the previous part had a great comment from Ross Harmes that explained the thinking behind it:

I can speak to why we use onclick in this situation. For performance reasons, we want to load as little JS as possible until the page content is fully loaded. We also don’t want to litter the page with script blocks just to attach these interim events. These two constraints mean that we can’t load a library that normalizes event handling across browsers, nor can we attach event listeners in the standard way, using JS only. onclick is the only approach left to us, but it isn’t a bad one. Like you said, we try to not be too dogmatic about these things.