// ----------------------------------------------------------
// A short snippet for detecting versions of IE in JavaScript
// without resorting to user-agent sniffing
// ----------------------------------------------------------
// If you're not in IE (or IE version is less than 5) then:
//     ie === undefined
// If you're in IE (>=5) then you can determine which version:
//     ie === 7; // IE7
// Thus, to detect IE:
//     if (ie) {}
// And to detect the version:
//     ie === 6 // IE6
//     ie > 7 // IE8, IE9 ...
//     ie < 9 // Anything less than IE9
// ----------------------------------------------------------
 
// UPDATE: Now using Live NodeList idea from @jdalton
 
var ie = (function(){
 
    var undef,
        v = 3,
        div = document.createElement('div'),
        all = div.getElementsByTagName('i');
 
    while (
        div.innerHTML = '<!--[if gt IE ' + (++v) + ']><i></i><![endif]-->',
        all[0]
    );
 
    return v > 4 ? v : undef;
 
}());

http://gist.github.com/527683

Staring keenly at a stack of magazines, I hazard a gaze towards the computer section and lay my eyes upon the newest cover of my sworn enemy, the .NET magazine. Its luring front-page convinces me that it deserves my consideration.

I buy it without looking inside. I want to reserve the surprise for later.

Now sitting in the lounge at London Gatwick Airport, I whip out the magazine and rush to a JavaScript article. I can’t wait. It’s about jQuery and I just know that they’ve gotten their act together since previous encounters. I’m sure this article will contain the best in jQuery techniques and JavaScript best practices.

Well, .NET, now I’m sitting here with the unfortunate duty to inform you of my unsurprising disappointment.

The truth is I expected nothing more from you.

Please turn to page 80 of issue 205 and pay special consideration to the following reservations of mine:

The author doesn’t mention the possibility nor the applicability of creating a jQuery plugin instead of the single globally defined function ‘drawerToggler’. What’s wrong with this? Well, the function happens to contain functionality that could be abstracted to deal with arbitrary sets of nodes and is therefore suited to jQuery’s plugin mechanism. I would understand if at least a mention surfaced, but nothing.

This is certainly not the worst of it though.

The function itself:

function drawerToggler() {
    $('#theme-drawer').slideToggle("normal", function(){
        if ($('#theme-drawer').is(":visible")) {
            $('#wrapper').css("margin-bottom", "150px");
        } else {
            $('#wrapper').css("margin-bottom", "20px");
        }
    });
}

Where it’s being called:

$(document).ready(function(){
    $('.drawer-toggler').click(function(){
        drawerToggler();
    });
});

This function is called within the click event handler for any element with a className containing drawer-toggler. Since it’s getting called on every click, and the elements selected within the drawerToggler do not change between calls, it would be logical to select and “cache” the DOM object references beforehand, and then the function could use these DOM references instead of continually (and redundantly) re-querying the DOM on every single call!

The function itself contains some redundant code too. The ‘theme-wrapper’ to which the slideToggle method is applied, is then re-queried within the callback. Apparently unbeknown to the author, this very element can be accessed via the ‘this’ keyword within the callback function — there is absolutely no need to re-query the DOM for #theme-wrapper!

This isn’t just a case of my preferences versus the author. There are established best practices in the jQuery community and as one of the industry’s top publications you should be providing not only good advice but near enough the best advice according to current industry practices and standards.

Now, I could stop, but the reign of nonsensical JavaScript programming continues.

On page 82, along with the insistence of using $(this).attr('rel') instead of the terser and faster DOM equivalent, this.rel, the author insists, again, on re-querying the DOM for unchanged elements within the click event handler for all anchor elements within #themes-wrapper!

There’s a few more specific issues I’d like to raise but I feel I’ve already made my point in regards to the obvious inadequacy of the article itself.

The article specifically says that it’s geared towards developers with an intermediate-level understanding of HTML, CSS and JavaScript. If you want to further the knowledge and understanding of these developers then you must, as reason would dictate, have a teacher that presents a higher-than-intermediate understanding of these technologies.

Before you suggest that I write an article to amend previously made mistakes (“Instead of complaining write your own article.. blah blah blah”) I’d like to let you know that I will do no such thing. It is your responsibility to find the best authors and the best content featuring the topic at hand.

I write this letter not only because I care, but because I am desperately worried, as are many others, about the state of jQuery within the JavaScript community, and more generally the lacking understanding that is slowly rotting the core principles of JavaScript from under its feet. Let the ignorance stain the ranks of beginners and hobbyists, as it always has and always will, but let it not protrude into a publication that claims to encapsulate the ever-changing essence of the web industry. Stop pandering to the lowest common denominator and be the best!

I realise that, from a monetary perspective, such concerns are likely to be lower on your priority list than getting that new coffee machine for your staff, but for the love of what you claim to stand for, prove to me that you are more than what I dare think you may just be — another profit-based publication whose sole concern is the quantity of its readership rather than the quality of its content.

If you’re going to publish articles relating to JavaScript then you’re going to have to tighten your belt and get to work. It’s not a playground. Currently, you’re only serving as a catalyst to the ignorance that a magazine such as yours should be out to destroy.

If you think this letter is not worthy of your consideration, then discard it as one of many (no doubt) complaints, for I am only too happy to accept that I’m right about you!

Prove me wrong. I dare you.

JAMES PADOLSEY

Be prepared for mildly offensive rhetoric and inappropriate usage of the ellipsis and exclamation mark!!!

• I think this universe is simply awesome. We’re quite tiny when everything is put into perspective. Heck, we’re just one form of life, on one planet, in one star system of hundreds of billions of star systems in this galaxy alone (which itself is accompanied by hundreds of billions of other galaxies), and yet some people still have the arrogance to feel that the human race is at the centre of the whole universe! Our wonderful yet miniscule existence is aptly covered in this beautifully poetic video from the late Carl Sagan.

• I think inline documentation, like that made possible with JSDoc, makes code ugly and unreadable. I want to see the code, and that’s all!
• I love the outdoors. I envy people that have jobs outside. And I don’t mean outside on the street cleaning up human sewage. I mean outside in the real world — the places that we haven’t yet destroyed.
• I think heavy UI abstractions like ExtJS totally take away all of the fun, excitement and challenges that should form a central part in any programmer’s role. To me, it looks like a product built for business people, and business people rarely understand the motives and desires of programmers — they only understand a couple of things: profit margins and economic viability.
• I’ve yet to sit in an office chair that won’t make my back hurt like hell after eight hours.
• I don’t believe in a God. I also don’t believe in fairies or unicorns.
• I get annoyed when people don’t realise the difference between believing that something doesn’t exist and rejecting the belief that something does exist, for it should be apparent that there is a huge difference.
• My favourite comedians of all time are Ricky Gervais, George Carlin, Frankie Boyle and Bill Hicks (watch all the videos!).
• I hate running, but I absolutely love cycling!
• I don’t understand Node.js. I really did try, but it just ended up confusing me. I’m not a Linux wizz so installing it was trouble enough.
• I think modern day advertising and marketing techniques are the bane of western society. Oh, and politicians!
• I didn’t care for the World Cup, and I always find it amusing how people shout at the TV and put flags on their cars when it won’t have the slightest effect on the game itself.
• I’m trying to become a vegetarian. Watch the documentary, Earthlings, and you’ll understand why.
• Pixar made me cry. I don’t know how they did it…
• I’d love to know how to play a musical instrument properly. Preferably the piano.
• I think humans have a responsibility to stop using non-renewable resources, but I don’t think playing the blame-game is helpful. I also don’t think change will happen given the current political and economic powers that be.
• I have a love-hate relationship with PHP. Doing most things is dead simple (which is great), but it’s such an ugly language!
• Even after all this time, jQuery is still my favourite JavaScript library. It’s small, intuitive and doesn’t require me to adopt a new programming paradigm!
• Other movies that have made me weep like a baby include The Stoning of Soraya M, Forrest Gump, The Champ and Pay It Forward.

Okay, that’s enough for today. Comment if you want. If you disagree with me on any of these points, then, GOOD! This world would be such a dull place without such varied opinions and people!

In this context, “unobtrusive” means affecting the page in a minimally invasive manner — minimal DOM destruction, no un-called-for normalizing of text nodes (i.e. joining separate text-nodes together) etc.

Essentially, what I’m talking about is finding a specific piece of text in a page or a piece of text that matches a pattern and then doing something with it — possibly wrapping it in an element or changing it in some other way.

Imagine that we have the following paragraph:

<p>This order's reference number is RF83297.</p>

We want to locate the reference number and wrap it in an anchor that leads to the order’s page (pretend that we’re making a bookmarklet to enhance the admin panel of some online store). Given what we know about the HTML structure this can be quite easy:

(Using jQuery)

jQuery('p').each(function(){
 
    var p = $(this);
 
    p.html(
        p.text().replace(
            /\bRF\d{5}/g,
            '<a href="/order/$&">$&</a>'
        )
    )
 
});

The problem with this approach is that it breaks once you add any elements to any of the paragraphs on the page. It sets the content of the the element to the (replaced) text of that very element, by definition destroying any non-text nodes in the process, or, to put it poetically, it flattens the DOM structure of any given paragraph.

Additionally, the above technique does not care to avoid paragraphs that do not contain a match for the pattern — it’ll blindly flatten all elements within the paragraphs…

Sure, we could fix it up a bit by making sure that it only messes with paragraphs that contain a match for the pattern (/\bRF\d{5}/g) but we’re still faced with the obtrusive destruction of each matching paragraph’s inner-DOM structure.

If there happened to be another link in the paragraph, it’d be wiped:

Before replacement:

<p>
    <a href="/admin">Go back to admin!</a><br/>
    This order's reference number is RF83297.
</p>

After replacement:

<p>
    Go back to admin!
    This order's reference number is <a href="/order/RF83297">RF83297</a>.
</p>

So, to be appropriately blunt, this is obviously a terrible technique and should be avoided at all costs.

EDIT: The reason it would also be a bad idea to do something like p.html( p.html.replace(...) ); is because you’d have to have some way of avoiding text in HTML attributes/tags (which, in itself, would require a messy regular expression) and you’d be destroying what elements currently exist within the paragraph — yes, the HTML would be the same following the replacement, but the elements themselves would have changed — meaning that event handlers and other bound data would be lost.

The right way

Whether we like it or not, the correct way to handle text in a DOM structure is to get intimate with the text nodes themselves. Text nodes aren’t that different from element nodes (the ones you’re used to dealing with) — the key differences are:

• Text nodes don’t have descendents (or childNodes).
• Almost everything you would want to know about a text node will be contained in its data (or nodeValue) property, which contains whatever text the node encapsulates.
• Text nodes don’t fire events, can’t have any styles applied, and are pretty useless at everything except holding a piece of text!

These text nodes will appear in the DOM structure just like element nodes. If we consider this paragraph again:

<p>
    <a href="/admin">Go back to admin!</a><br/>
    This order's reference number is RF83297.
</p>

Its DOM structure is as follows:

-> P ELEMENT
    -> TEXT NODE (data: "\n   ")
    -> A ELEMENT (href: "/admin")
        -> TEXT NODE (data: "Go back to admin!")
    -> BR ELEMENT
    -> TEXT NODE (data: "\n    This order's reference number is RF83297.\n")

Firebug’s your friend:

We don’t know which text node we’ll find the reference number in so our only choice is to traverse and test all text nodes, including the nested ones. This in itself is quite simple:

// Pretending we have more than one paragraph to look through
jQuery('p').each(function(){
    traverseChildNodes(this);
});
 
function traverseChildNodes(node) {
 
    var next;
 
    if (node.nodeType === 1) {
 
        // (Element node)
 
        if (node = node.firstChild) {
            do {
                // Recursively call traverseChildNodes
                // on each child node
                next = node.nextSibling;
                traverseChildNodes(node);
            } while(node = next);
        }
 
    } else if (node.nodeType === 3) {
 
        // (Text node)
 
        if (/\bRF\d{5}/.test(node.data)) {
            // Do something interesting here
            alert('FOUND A MATCH!');
        }
 
    }
 
}

Finding a match isn’t too tricky, but replacing the matched portion of a text node with an element (wrapping it with the anchor) can be troublesome. Fortunately we can call on the useful innerHTML trick to create an out-of-DOM collection of nodes and add them one by one.

First, let’s adjust our traverseChildNodes so that it calls wrapMatchesInNode whenever it finds a node that matches:

// ....
} else if (node.nodeType === 3) {
 
    // (Text node)
 
    if (/\bRF\d{5}/.test(node.data)) {
        wrapMatchesInNode(node);
    }
 
}
// ....

wrapMatchesInNode:

function wrapMatchesInNode(textNode) {
 
    var temp = document.createElement('div');
 
    temp.innerHTML = textNode.data.replace(/\bRF\d{5}/g, '<a href="/order/$&">$&</a>');
 
    // temp.innerHTML is now:
    // "\n    This order's reference number is <a href="/order/RF83297">RF83297</a>.\n"
    // |_______________________________________|__________________________________|___|
    //                     |                                      |                 |
    //                 TEXT NODE                             ELEMENT NODE       TEXT NODE
 
    // Extract produced nodes and insert them
    // before original textNode:
    while (temp.firstChild) {
        console.log(temp.firstChild.nodeType);
        textNode.parentNode.insertBefore(textNode, temp.firstChild);
    }
    // Logged: 3,1,3
 
    // Remove original text-node:
    textNode.parentNode.removeChild(textNode);
 
}

That’ll work quite nicely. The result:

<p>
    <a href="/admin">Go back to admin!</a><br/>
    This order's reference number is <a href="/order/RF83297">RF83297</a>.
</p>

But now we face another problem…

A given chunk of text in a DOM snippet is not guaranteed to be encapsulated within a single text node. The HTML parsed by the browser will produce single DOM nodes from uninterrupted strings of text, such as what’s within this DIV:

<div>
    Nothing but text.
    No elements.
    No comments.
    Nada...
</div>

… But, any extra text appended to that element will not merge into the already-existing text node, unless, of course, you’re using innerHTML/innerText (/textContent) to set your content.

So, it’s possible — not likely, but possible that we will encounter our reference number in two or more text nodes. For example:

-> TEXT NODE (data: RF)
-> TEXT NODE (data: 832)
-> TEXT NODE (data: 97)

This occurance will not be noticed by our current solution, since it treats each text-node as its own “haystack”.

Before we discuss solutions to this, we must first cover other potential issues. Consider this:

<span>RF</span>83297

A similar problem occurs here — the text is separated, both parts in separate text-nodes — one nested in an element. It may seem as though I’m stretching the reference-number example but please remember that it’s just an example: what I’m trying to cover is the complexities involved in getting what is seemingly a simple operation to work correctly.

If we are to match a string of text, even when part of it is wrapped in arbitrary elements (like above), what elements should we allow? Surely not block-level elements? Well, of course, but this means that we need to test the computed style of every traversed element to see if its “inline” or otherwise.

Let’s consider an abstraction that solves all the covered issues. It let’s you search a specified root node for occurrences of a string and let’s you replace with whatever HTML you want — allowing you to wrap it in an anchor element, for example. But, what happens in cases like this:

<p>
    ...
    This order's reference <em>number is RF</em>83297.
</p>

Wrapping RF</em>83297 in <a>...</a> would produce invalid HTML…

So it seems that, while possible, a solution that protects against all of the potential problems is likely to be slow and, in the end, simply not worth it.

The only viable solution, in my eyes, is to forget about matching strings that are interrupted with HTML elements (like <em>RF</em>83297). Only test text-node data, and to handle neighbouring text nodes merge them together or to be truly “unobtrusive” collect up data in neighbouring text nodes and test the collected text at the end.

That’s really all I have to say on the matter. I hope I didn’t coerce you down the rabbit hole with the false promise of an all-encompassing solution… I simply don’t have one!

It is a “Fairy” generator that creates small pulsating elements and moves them around the viewport in random directions, but not too eratically. You can load some fairies on this page by clicking this bookmarklet!

The original problem was that I had been mentally locked-in to a specific type of animation on the client-side and I would sit there thinking, “Okay, how do I animate this element from ‘a’ to ‘b’ while taking random detours and going in random directions?”… I was still in the conventional client-side animation mindset, where you take an element and call an animation function to mutate certain CSS properties over a specified duration. The prospect of doing it via manual calls to setInterval, with delta-x/y values never crossed my mind.

Eventually it became clear that this would be the only way to make the fairies fly as I wanted — i.e. not to simply go from ‘a’ to ‘b’, but to continually fly around in all directions.

I started with an environment singleton instance, named “fairyEnvironment”, containing the various bounds and rules attributed to the current document:

var fairyEnvironment = new function() {
 
    this.bounds = {
        left: 0,
        top: 0,
        right: 0,
        bottom: 0
    };
 
    this.speedLimit = {
        high: 6,
        low: 2
    };
 
    this.spawn = function(amount, postCreation, config) {
 
        var ret = [], i = -1;
 
        amount = ~~amount
 
        while (++i < amount) {
            postCreation &&
                postCreation.call(
                    ret[i] = new fairyEnvironment.Fairy(config)
                );
        }
 
        return ret;
 
    };
 
};

The generated fairies would have to stay within a specific area, defined by the bounds, “top”, “left”, “right” and “bottom”. I also specified the upper and lower speed limit and a function to spawn multiple Fairy instances at once. You can see that I’ve referenced fairyEnvironment.Fairy, which is defined as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

fairyEnvironment.Fairy = function Fairy(config) {
 
    // Config is optional, defaults apply
    config = config || {};
 
    this.bounds = fairyEnvironment.bounds;
    this.speedLimit = fairyEnvironment.speedLimit;
 
    this.timer;
 
    // If no width is specified then generate width between 10 and 30
    this.width = config.width || 0 | Math.random() * 20 + 10;
    this.height = config.height || this.width;
 
    this.opacity = 1;
    this.dOpacity = Math.random() * .1;
 
    // If no speed is specified then genarate a random width between
    // the upper and lower limits specified in FairyEnvironment
    this.speed = config.speed || Math.random() *
                 (this.speedLimit.high - this.speedLimit.low)
                 + this.speedLimit.low;
 
    this.dX = 0;
    this.dY = 0;
 
    // Setup an arbitrary direction (to get things rolling)
    this.shiftDirection();
 
    // If no color is specified then generate one randomly
    // Note that this will generate intensities between 155 and 255
    this.color = config.color || [
        0|Math.random()*100+155,
        0|Math.random()*100+155,
        0|Math.random()*100+155
    ];
 
    // Spawn the fairy somewhere random
    this.y = Math.random() * (this.bounds.bottom - this.height);
    this.x = Math.random() * (this.bounds.right - this.width);
 
    // Build the canvas
    // Note, this doesn't HAVE to be a canvas - it could
    // just be a regular DOM element
    this.dom = this.build();
 
    // set initial position
    if (this.dom) this.step(); 
 
};

The dX and dY properties are probably the most important. The ‘d’ stands for “delta” which means the difference between two things — here it means the change that the x and y properties will experience on each step of the animation. So, if dX is set to 5 then the fairy will move five pixels to the right on every step of the animation. The dX and dY values can be changed at any time, before or after each step, thus producing changes in speed and direction.

The speed property (line 20) defines the limits of dX and dY. So, if the speed is set as 10 then the delta values can only go up to ten (either positive or negative) — so, dX would be able to change from -10 to +10.

I’ve also used both the double-bitwise-not (~~) and bitwise-or (| – but with zero as left-hand operand – 0|) operators quite a lot — in essence, they both floor the right-hand-side operand (i.e. number -> integer). They’re better than Math.floor because they return a number (zero) even from Undefined, Null, NaN, and Infinity operands. 0| is used instead of ~~ in some places simply because | (bitwise-or) has a lower precedence than ~ (bitwise-not), meaning that it can be used in expressions like 0|a*b+c without having to wrap a*b+c in parenthesis (i.e. ~~(a*b+c)). You can read more about this “flooring” operation here.

I’ve also used Math.random() a lot, e.g.

// If no color is specified then generate one randomly
// Note that this will generate intensities between 155 and 255
this.color = config.color || [
    0|Math.random()*100+155, // Red
    0|Math.random()*100+155, // Green
    0|Math.random()*100+155  // Blue
];

Generating a random number between two bounds is quite simple:

Math.random() * (upperBound - lowerBound) + lowerBound

Math.random() generates a number from zero to just below one (never one). Note that the lower bound is inclusive and the upper bound is exclusive.

This generated color is used when creating and painting the canvas:

/* fairyEnvironment.Fairy.prototype = { ... */
build: function() {
 
    // Create <canvas>
 
    var c = document.createElement('canvas'),
        _ = c.getContext && c.getContext('2d'),
        color = this.color;
 
    if (!_) {
        // Just for IE :D
        var d = document.createElement('div');
        d.style.fontSize = '12px';
        d.style.fontFamily = 'monospace';
        d.style.position = 'absolute';
        d.style.color = '#FFF';
        d.style.background = '#000';
        d.innerHTML = 'IE SUCKS';
        this.width = 48;
        return d;
    }
 
    c.width = this.width;
    c.height = this.height;
 
    // Create radial gradient to make it Fairy-like
    var grad = _.createRadialGradient(
        this.width/2,
        this.height/2,
        0,
        this.width/2,
        this.height/2,
        this.width/2
    );
 
    grad.addColorStop(0, 'rgba(' + color.join() + ',1)');
    grad.addColorStop(1, 'rgba(' + color.join() + ',0)');
 
    _.fillStyle = grad;
    _.fillRect(0, 0, this.width, this.height);
 
    c.style.position = 'absolute';
 
    return c;
 
}/*,...};*/

Jacob Seidelin’s canvas cheatsheet was infinitely useful during this endeavour. I don’t yet use canvas enough to know its API well enough — one day perhaps…

As you can see in the Fairy constructor, the return value of build() is assigned to instance.dom (line 43: this.dom = this.build();). Whoever instantiates the fairy is expected to add the canvas to the document. A simple example:

var myFairy = new fairyEnvironment.Fairy();
document.body.appendChild(myFairy.dom); // append to document
myFairy.start();

Or, with our useful spawn method:

fairyEnvironment.spawn(25, function(){
    document.body.appendChild(this.dom);
    this.start();
});

Calling start() begins the animation with a simple call to setInterval:

start: function() {
    var hoc = this;
    this.timer = setInterval(function(){
        hoc.step();
    }, 30);
}

The step() method is run every 30 milliseconds, which equates to about 33 frames per second. It could probably be made a little more infrequent though -- although the jury is still out on the perfect FPS.

The step() method involves a number of simple operations. This is where abstraction really starts to shine:

step: function() {
 
    if (!this.detectEdges()) {
        this.shiftDirection();
    }
 
    this.limitSpeed();
 
    this.dom.style.left = ~~(this.x += this.dX) + 'px';
    this.dom.style.top = ~~(this.y += this.dY) + 'px';
 
    this.pulse();
 
}

With the right level of abstraction and proper naming one can do away with the clutter caused by the overuse of comments. The only possibly questionable area in the above method is this:

this.dom.style.left = ~~(this.x += this.dX) + 'px';
this.dom.style.top = ~~(this.y += this.dY) + 'px';

We've already established what ~~ does. One important thing that happens here, which would be easy to miss, is the expression this.x += this.dX which adds the dX (delta-x) value to the current x value and then returns the result of that addition. Retaining state using this.x is much better than having to re-query this.dom.style.left on every step.

As logic would dictate, the detectEdges() method determines whether the fairy is too close to any of the bounds specified in fairyEnvironment.bounds, and if it is then it takes action by calling turnAway().

detectEdges():

detectEdges: function() {
 
    // If the fairy is too close to an edge (padding is fixed at 60px)
    // then slowly turn away... 
 
    var x = this.x,
        y = this.y,
        w = this.width,
        h = this.height,
        bounds = this.bounds,
        padding = 60;
 
    if (x < padding + bounds.left) return this.turnAway(this.LEFT_EDGE);
    if (y < padding + bounds.top) return this.turnAway(this.TOP_EDGE);
    if (x + w > bounds.right - padding) return this.turnAway(this.RIGHT_EDGE);
    if (y + h > bounds.bottom - padding) return this.turnAway(this.BOTTOM_EDGE);
 
}

turnAway():

turnAway: function(fromEdge) {
 
    if (fromEdge === this.TOP_EDGE || fromEdge === this.BOTTOM_EDGE) {
        // SLowly start inverting Y
        this.dY += fromEdge === this.TOP_EDGE ? 1 : -1;
        this.compensate('X');
    } else {
        // Slowly start inverting X
        this.dX += fromEdge === this.LEFT_EDGE ? 1 : -1;
        this.compensate('Y');
    }
 
    return true;
 
}

The compensate() method takes a single axis as its argument and makes sure that the full speed of the fairy is being expressed on both dX and dY. For example, if the speed is 10 and dX has been set to 3, then compensate will change dY to either -7 or +7 dependent on its current direction. abs(dX) plus abs(dY) must always equal speed.

The shiftDirection() method is called by step(), but only when the fairy is not near any edges. This method will randomly shift the direction of the fairy:

shiftDirection: function() {
 
    // Only change direction 30% of the time
    if (Math.random() > .7) {
        this.dX += Math.random() * 2 - 1; // between 1 & -1
        this.compensate('Y');
    }
 
}

I might make this configurable in the future but right now it will only change the direction 30% of the time, and only one pixel at a time.

The pulsating opacity of the fairies is achieved with a very rudimentary pulse() method:

pulse: function() {
 
    if (this.opacity >= 1 || this.opacity <= .6) {
        this.dOpacity = -this.dOpacity;
    }
 
    this.dom.style.opacity = this.opacity += this.dOpacity;
 
}

The opacity pulses between 0.6 and 1. dOpacity is set in the Fairy constructor to a number between zero and 0.1:

16

this.dOpacity = Math.random() * .1;

That's it!

Like I said: quite pointless yet quite fun. You can check out the Github repo over here:

"Fairy" on Github

The bookmarklet

The bookmarklet loads the Fairy script from Github and then spawns 25 fairies. It also listens for the window's scroll and resize events so that it can change the bounds of fairyEnvironment according to where you are in the document. You can see this in action by clicking this and then scrolling up or down -- the fairies will follow you.

bookmarklet-demo.fairy:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

(function(){
 
    if (window.fairyEnvironment && fairyEnvironment.Fairy) {
        return init();
    }
 
    var s = document.documentElement.appendChild(document.createElement('script')),
        t = setInterval(function(){
            if (window.fairyEnvironment && fairyEnvironment.Fairy) {
                clearInterval(t);
                s.parentNode.removeChild(s);
                init();
            }
        }, 50);
 
    s.src = 'http://github.com/jamespadolsey/Fairy/raw/master/fairy.js';
 
    function init() {
 
        var d = document.body.appendChild(document.createElement('div')),
            docEl = document.documentElement,
            body = document.body,
            winHeight,
            resize = function() {
 
                winHeight = window.innerHeight ||
                            docEl.clientHeight ||
                            body.clientHeight;
 
                fairyEnvironment.bounds.right =
                    Math.max(docEl.clientWidth, docEl.offsetWidth);
 
                scroll();
 
            },
            scroll = function() {
 
                fairyEnvironment.bounds.top =
                    Math.max(
                        ~~window.pageYOffset,
                        body.scrollTop,
                        docEl.scrollTop
                    );
                fairyEnvironment.bounds.left =
                    Math.max(
                        ~~window.pageXOffset,
                        body.scrollLeft,
                        docEl.scrollLeft
                    );
                fairyEnvironment.bounds.bottom =
                    fairyEnvironment.bounds.top + winHeight;
 
            };
 
        resize();
 
        if (window.addEventListener) {
            window.addEventListener('resize', resize, false);
            window.addEventListener('scroll', scroll, false);
        } else {
            window.attachEvent('onresize', resize);
            window.attachEvent('onscroll', scroll);
        }
 
        fairyEnvironment.spawn(25, function(){
            if (this.dom) {
                d.appendChild(this.dom);
                this.start();
            }
        });
 
    }
 
}());

I feel that there are bad events too though — events that we feel we must utilise just because they exist — and we feel we must build into our APIs just because event-driven design dictates absolute submission to this way of thinking.

DOM mutation events

Every single time I’ve ever considered using a DOM-mutation event I’ve subsequently discovered that the problem can be better solved by re-architecting the codebase. The DOM2 mutation events aren’t well supported in less capable browsers but offer an interesting opportunity — to listen for document mutation such as attribute changes, node insertion and node removal.

This sounds cool and I’m sure your mind was buzzing with ideas when you first heard about these events, but have you actually encountered a situation where utilising these events is the only viable solution? If so, I’d love to hear it.

Programmatic events

This is where I lose all sense of comprehension. The premise is a mechanism that allows you to be notified when changes occur to your program — i.e. your objects, arrays and functions. I’m talking about the likes of Object.prototype.watch, IE’s onPropertyChange and a tonne of other new implementations (e.g.) that seem to perpetuate a dangerous disconnect of cogs that should be working together.

It seems pointless — it’s akin to starting your car, and then being notified by the car that you just started the car… an entirely redundant notification.

var a = abstraction.Array(1,2,3);
a.push(4);
// > Abstraction says: "You just changed the array"
// > Me says: "OH RLY"

Left hand, meet right hand!

Events exist so that processes outside the scope of your code can communicate with your code and let you know when certain things occur. Events typically operate up the abstraction chain — you listen for events from lower-level abstractions. I feel that the “outside the scope of your code” aspect is central to the whole concept of events and is why they make so much sense in a browser-scripting environment. The browser listens to events from the operating system and forwards certain events to the DOM where we can listen for them. It’s a simple fluid concept that works!

There’s a lot of hype surrounding event-driven programming/design at the moment and it seems that we’re approaching a risky threshold, where events are used just because they can be, and not because they should be.

If you’re creating an app, and it requires a great deal of client-side functionality, then you’re going to need to interface with the DOM to listen for events and apply certain changes. This is what JavaScript is all about. You write the logic layer of code (your own personal API) and then you write the implementation code that utilises the logic layer. You have authored two distinct layers of abstraction. That’s pretty much the gist of what we do.

What’s approaching, it seems, is an era of haphazard juggling of third-party scripts, multiple abstractions, multiple APIs and consequently, dozens of events. No need to write a consistently encapsulated logic layer — you can just bung these plugins/modules/classes into the app… To heck with maintenance, clean and consistent abstractions, intuitive APIs, self-documenting code and all sense of originality.

I’m not questioning events in general, and I will admit that they can be very helpful to make two scripts work together, but as I mentioned, I feel there’s a threshold where it becomes simply foolish…

Within each textbox enter what you think the piece of code above it returns.

• The pieces of code are executed as statements.
• Enter your answer as if you were typing the code literally. So, if the answer is the string "foo", then type "foo" (including the quotes — double or single), and if it’s an array like [1,2,3] then type it out just like that.
• If you think an error is thrown then enter ERROR in the appropriate textbox.
• When there are multiple statements, type what the last statement returns.

Please access this post directly in order to take the quiz (note: JavaScript must be enabled).

Like I said, it doesn’t test your everyday knowledge of JS, but your comprehension of the specification. Feel free to post results and discuss the quiz!

I’ll eventually post a comment with all the answers (plus explanations), assuming nobody beats me to it.

If you want to have a go at creating your own jQuery-like DOM library, here’s something to get you started:

window.myWrapper = (function(){
 
    // "cache" useful methods, so they don't
    // have to be resolved every time they're used
    var push = Array.prototype.push,
        slice = Array.prototype.slice,
        toString = Object.prototype.toString,
 
        isArray = function(o) {
            toString.call(o) === '[object Array]';
        },
 
        toArray = (function(){
 
            try {
 
                // Return a basic slice() if the environment
                // is okay with converting NodeLists to
                // arrays using slice()
 
                slice.call(document.childNodes);
 
                return function(arrayLike) {
                    return slice.call(arrayLike);
                };
 
            } catch(e) {}
 
            // Otherwise return the slower approach
 
            return function(arrayLike) {
 
                var ret = [], i = -1, len = arrayLike.length;
 
                while (++i < len) {
                    ret[i] = arrayLike[i];
                }
 
                return ret;
 
            };
 
        })();
 
    function NodeList(elems) {
 
        this.length = 0;
 
        push.apply(
            this,
            elems.nodeType ?
                [elems] // Single node
                : isArray(elems) ?
                    elems // Real array
                    : toArray(elems) // NodeList/Array-like-object
        );
 
    }
 
    function myWrapper(elems) {
        // Instantiate and return new NodeList
        return new NodeList(elems);
    }
 
    myWrapper.NodeList = NodeList;
 
    NodeList.prototype = {
 
        each: function(fn) {
 
            for (var i = -1, l = this.length; ++i < l;) {
                fn.call(this[i], this[i], i, l, this);
            }
 
            return this;
 
        }
 
    };
 
    return myWrapper;
 
})();

There’s no selector engine, but it’s easy enough to slot one in:

function myWrapper(elems) {
    // E.g. using Sizzle as the selector engine
    return new NodeList( typeof elems === 'string' ? Sizzle(elems) : elems );
}

Example of usage:

myWrapper(document.getElementsByTagName('div')).each(function(){
    alert(this.id);
});
// Etc.

Extending NodeList:

myWrapper.NodeList.prototype.applyCSS = (function(){
 
    var hasOwn = Object.prototype.hasOwnProperty;
 
    return function(props) {
 
        for (var i = -1, l = this.length; ++i < l;) {
            for (var p in props) {
                if (hasOwn.call(props, p)) {
                    this[i].style[p] = props[p];
                }
            }
        }
 
        return this;
 
    };
 
}());
 
// Usage:
myWrapper(document.body).applyCSS({
    background: 'red',
    color: 'yellow'
});

This is no fault of jQuery’s but this practice of redundant “wrapping” generally sucks.

I “tweeted” a while ago, complaining of this:

Constructing a new jq obj on each iteration just to access some text seems wrong. jQuery(‘a’).map(function(){ return $(this).text(); });

Paul Irish suggested that I use jQuery.text instead of jQuery.fn.text, meaning that I wouldn’t have to bother with constructing a new jQuery object every single time my function was called. This was a good suggestion but unfortunately not all of jQuery’s methods have corresponding single-node functions, and it would mean not being able to chain methods.

This is a growing problem, and is only worsened by developers’ insistence on constructing multiple jQuery objects with the same element! -

jQuery('a').click(function(){
 
    if (jQuery(this).attr('href') === 'blah') {
        jQuery(this).next('.whatever').slideToggle();
    }
 
    jQuery(this).fadeTo('slow', 0.4);
 
    return false;
 
});

Eew! Not only are there multiple pointless constructors, but Mr. Uber Cool jQuery Developer isn’t accustomed to the DOM, so has absolutely no idea that, in most situations, this.href would suffice for getting the href property value. This kind of misuse has been discussed in step #3 here: http://encosia.com/2010/03/30/5-steps-toward-jquery-mastery/.

The real problem remains that there are three jQuery objects being constructed, — I feel that it is a library’s obligation to protect against misuse like this. Even if you’re only constructing one jQuery object in a callback it’s still somewhat pointless, in that you’re only doing so to call a couple of methods…

In light of my concerns I thought it would make sense to experiment with some ways to alleviate this troublesome situation. In the end, I landed on something so dead-simple that I feel silly even shining a spotlight on it:

jQuery.single=function(a){return function(b){a[0]=b;return a}}(jQuery([1]));

76 characters. Here’s the readable version:

jQuery.single = (function(o){
 
    var collection = jQuery([1]); // Fill with 1 item, to make sure length === 1
 
    return function(element) {
 
        // Give collection the element:
        collection[0] = element;
 
        // Return the collection:
        return collection;
 
    };
 
}());

A single jQuery object is being created and is then used for every single call to jQuery.single — so only one jQuery object is ever being created. If you think about it, we tend to wrap elements in jQuery(...) (i.e. in a jQuery instance) so that we can have access to jQuery’s methods. Very rarely do we mutate the object itself — even when you call parent() or children(), the jQuery object itself isn’t being changed — a new object is being returned. It’s this non-mutability which makes this solution viable.

Obviously, you can’t use it in exactly the same was as jQuery(); jQuery.single will only work when you pass a single DOM element. Here’s an example of its usage:

jQuery('a').click(function(){
 
    var html = jQuery.single(this).next().html(); // Method chaining works!
 
    alert(html);
 
    // etc. etc.
 
});

Also, you can’t cache it and save it for later as you normally would… well, actually, you can — but the object will change when you next call jQuery.single, so be careful! And please note that this is only meant to be used in situations where you have a DOM element that requires immediate wrapping.

You might be thinking that we could do away with this trickery by simply remembering to “cache” our jQuery objects, like so (using the example from before):

jQuery('a').click(function(){
 
    var me = jQuery(this);
 
    if (me.attr('href') === 'blah') {
        me.next('.whatever').slideToggle();
    }
 
    me.fadeTo('slow', 0.4);
 
    return false;
 
});

This is a good practice, but is still not quite as speedy as jQuery.single. I absolutely recommend making up your own mind by carrying out your own tests, but having tested jQuery.single() myself I can tell you that it performs better.

You can make it even faster by assigning jQuery.single to a (closely-scoped) variable:

var $_ = jQuery.single;
 
// Use $_(this) ...

I’ll use the example of a really simple “getJSONP” function:

// BEFORE
function getJSONP(url, success) {
 
    var ud = '_' + +new Date,
        script = document.createElement('script'),
        head = document.head || document.getElementsByTagName('head')[0]
                             || document.documentElement;
 
    window[ud] = function(data) {
        head.removeChild(script);
        delete window[ud];
        success && success(data);
    };
 
    script.src = url.replace('callback=?', 'callback=' + ud);
    head.appendChild(script);
 
}
 
// AFTER
function getJSONP(url, success) {
 
    declareVars: {
        var ud = '_' + +new Date,
            script = document.createElement('script'),
            head = document.head || document.getElementsByTagName('head')[0]
                                 || document.documentElement;
    }
 
    defineCallback: {
        window[ud] = function(data) {
            head.removeChild(script);
            delete window[ud];
            success && success(data);
        };
    }
 
    addScriptToDocument: {   
        script.src = url.replace('callback=?', 'callback=' + ud);
        head.appendChild(script);
    }
 
}

You may think that doing this borders on totally pointless and in this instance I’d probably agree, but you must admit it could potentially be useful in other situations (none come to mind though).

We’re normally used to { and } being used to delimit an object literal, but they can also be used to create blocks (or “compound statements”). A compound statement is a statement that contains any number of sub-statements. We use them all the time:

while (true) normalStatement;
while (true) {
    iAmInACompoundStatement;
    soAmI;
    ermICallItABlock;
}

We use them everywhere, if statements, for statements, while statements, switch statements, try/catch statements …

Since JavaScript doesn’t have block scope, using a block anywhere other than in the conventional places (if/while etc.) is almost totally pointless. However, as I mentioned, we could use them to annotate and contain logically related pieces of code:

definingMyVar: var x = 123;
 
definingABunchOfVars: {
    var x = 123,
        y = 456,
        z = 789;
}

We can even use break within these blocks:

var x = 1;
 
foo: {
    x = 2;
    break foo;
    x = 3;
}
 
x === 2;

Note that the break statement must include a label, otherwise it’s invalid; unlabelled break/continue statements are only permissible within switch statements and loops.

I dare say this is all quite pointless… but very interesting nonetheless. What say you?