The following quote is derived from an expert recommended book that covers the many aspects of Ajax. It’s called “Ajax in Action”, authored by Dave Crane, Eric Pascarello, and Darren James.

“The JavaScript Object Notation (JSON) is a core feature of the language [JavaScript]. It provides a concise mechanism for creating arrays and object graphs. In order to understand JSON, we need to know how JavaScript arrays work [...]”

Hopefully you’ve spotted the dodgy parts of that quote. For one, JSON, the data-interchange format is not actually a core feature of JavaScript and is, in more ways that one, quite different to JavaScript’s object notation (i.e. the way you markup an object literal in JavaScript code).

Despite my dismay I continued to read onwards, and I can tell you that the author has also made the classic mistake of thinking that JavaScript supports associative arrays, and for some reason thinks that you have to understand JavaScript arrays in order to understand JSON… (???)

So, just to set the record straight, JSON is an interchange format created/coined by Doug Crockford. It’s a subset of JavaScript’s object notation (specified in the ECMA-262 specification). To prove this, here’s a valid JavaScript object literal:

{
    foo: 123,
    bar: 456
}

Yes, I know, on its own it’s not valid JavaScript (since it’s interpreted as a compound statement), but that doesn’t matter; it is a valid object literal.

Run that through a JSON validator and you’ll get errors. That’s because JSON is not the same as JavaScript’s object notation. To make the above code a valid piece of JSON you’d have to wrap each property name (e.g. foo) with double quotes:

{
    "foo": 123,
    "bar": 456
}

I don’t blame the author of that book. In all likelihood, the information within that book was thought of as 100% correct at the time of writing. I only wanted to set-straight one of many misconceptions surrounding JavaScript and its “subsets”.

PS. Please forgive the confusing title.

A while ago I posted a method I had been using at the time to remove comments from JavaScript code. It was pretty decent – instead of using a regular expression it steps through each character and removes comments where it finds them.

At the time I thought stepping through a string character-by-character was the only reliable way to solve the “comments problem” but after giving it another attempt I found that it was possible with a only a few regular expressions and a fairly moderate dose of JavaScript’s replace() function.

Here it is:

function removeComments(str) {
 
    var uid = '_' + +new Date(),
        primatives = [],
        primIndex = 0;
 
    return (
        str
        /* Remove strings */
        .replace(/(['"])(\\\1|.)+?\1/g, function(match){
            primatives[primIndex] = match;
            return (uid + '') + primIndex++;
        })
 
        /* Remove Regexes */
        .replace(/([^\/])(\/(?!\*|\/)(\\\/|.)+?\/[gim]{0,3})/g, function(match, $1, $2){
            primatives[primIndex] = $2;
            return $1 + (uid + '') + primIndex++;
        })
 
        /*
        - Remove single-line comments that contain would-be multi-line delimiters
            E.g. // Comment /* < --
        - Remove multi-line comments that contain would be single-line delimiters
            E.g. /* // <-- 
       */
        .replace(/\/\/.*?\/?\*.+?(?=\n|\r|$)|\/\*[\s\S]*?\/\/[\s\S]*?\*\//g, '')
 
        /*
        Remove single and multi-line comments,
        no consideration of inner-contents
       */
        .replace(/\/\/.+?(?=\n|\r|$)|\/\*[\s\S]+?\*\//g, '')
 
        /*
        Remove multi-line comments that have a replaced ending (string/regex)
        Greedy, so no inner strings/regexes will stop it.
       */
        .replace(RegExp('\\/\\*[\\s\\S]+' + uid + '\\d+', 'g'), '')
 
        /* Bring back strings & regexes */
        .replace(RegExp(uid + '(\\d+)', 'g'), function(match, n){
            return primatives[n];
        })
    );
 
}

Theoretically this should work perfectly in almost all situations. Don’t bother even trying it with E4X as that definitely won’t work! E.g.

var someE4X = <box>// this is NOT a comment</box>;

It's impossible to cater to E4X with regular expressions because XML is a recursive structure. I'm not bothered though as E4X isn't exactly a widely used extension. It also doesn't play well with conditional compilation but frankly, conditional compilation shouldn't exist anyway.

Anyway, back to the solution. It takes a pretty conventional approach of removing all strings and regular expressions first and then moving on to the comments. Unfortunately comments are not as simple as \/\*.+?\*\/ - there are nested comments within strings, nested comments within literal-regular-expressions and nested comments within other comments.

I better do some explaining after that unnecessarily provocative title… jQuery is obviously a fantastic JavaScript library and has been my tool of choice for quite a while now, and it’ll probably continue that way until something better comes along. What I wanted to discuss today though has nothing to do with the technical aspect of jQuery but rather the plugin culture that’s formed around it and some of the possibly negative effects of this culture.

The problem I’m about to outline may be inherent of other plugin cultures within other libraries too but I won’t dare mention them at the risk of starting a flame war. This isn’t really about jQuery, this is about a much larger problem which has proven to be unavoidable and unstoppable on a platform as pervasive as the internet.

So here’s the problem: Joe Average needs some “cool JavaScript stuffs” to impress his client – he hops over to the plugin repository (more likely, Google) and searches for some specific jQuery plugins. After choosing the plugins he desires he will delegate to each one a certain chunk of responsibility – the cycle plugin gets the featured-banner, the validation plugin gets all the forms, and the tooltip plugin gets the navigation menu, and the list goes on. By the end, Joe has 5 plugins he wants to use on his newly developed website. So, like any innocent developer he sticks them all in the <head> and calls it a job well done!

There are over 3000 plugins in the jQuery plugin repository and probably multiples of that amount floating around elsewhere. With so much functionality at the tip of our fingers it’s no wonder that most of us have succumbed to the notorious copy-and-pasting-syndrome.

The jQuery plugin culture is essentially just an extension of this. Sure, many of the plugins are much more reliable than any random code snippet but it’s still the same. I think this “syndrome” protrudes most significantly into jQuery because of its popularity amongst people that have no interest in JavaScript whatsoever… I’m talking about the thousands of designers and interface-engineers who use jQuery on a daily basis yet have no interest and very little knowledge when it comes to JavaScript and its various abstractions. To these people it seems okay to bombard users with a symphony of jQuery-chaos at the expense of many-hundreds of kilobytes of mostly-useless JavaScript code.

The most popular jQuery plugins have been made to suit many different situations. Let’s take the “cycle” plugin by Mike Alsup as an example – it’s a very well built plugin that is very easy to integrate and even simpler to customise. The one problem with it though, and this is inherent of all the most popular plugins, is that it tries to cater to every conceivable usage at once. This results in 20kb (at minimum) of mostly unused code. Most users of this plugin will probably use only one or two of its features on any particular website. If they were to write the desired functionality from scratch than I doubt it would take up any more than 2kb. I may be over-simplifying and making many assumptions but it’s an undeniable fact – there is a problem with this plugin-model. As it currently stands, the model offers only a marginal benefit to the user… suddenly, it’s all about the developer!

There’s an obvious cost – if building the functionality from scratch results in only 2kb yet using the plugin is a monstrous 20kb then the cost of using the plugin is 18kb. We don’t feel the brunt of it though – it’s our users that suffer. Note that I’m not talking about the monetary cost (as a business would see it); and this really shouldn’t be considered at all – when it comes to doing the right thing, money is no object!

There are obvious exceptions to the outlined problem though; not all plugins try to do everything at once and not all plugins are that huge but the crux persists: these plugins are used as if they were throw-away snippets, integrated on a whim by some designer that thinks “jQuery rulez!”

This is probably contrary to the concept of code-reuse but this is what I tend to do: If I need a piece of functionality and if I know how it’s achieved then I’ll build it myself. Some may think it foolish to constantly re-invent the wheel but I would have to disagree – doing this allows you to progress as a flexible developer – one who can confront many different problems without having to rely on multiple abstractions.

There are times when I’ll gladly use someone else’s code but it’s normally only when that code caters to a very specific problem that is quite unique and difficult to solve. For example, I use the history plugin a lot! It does just one thing and it does it very well!

jQuery itself is a massive abstraction and has closed the gap between those-who-can’t and those-who-can. Do you really need any more? I’m not saying you should stop creating and using plugins, I’m simply saying that the usage of any particular plugin needs to be carefully considered! Remember, it’s not about you, it’s about the users!

Here’s a nifty little trick that allows you to write “contextual” JavaScript. It’s incredibly obtrusive and probably shouldn’t be used at all but it’s still a pretty cool idea:

<div id="some-div">
    <script type=":contextual">
        alert(this.id); // "some-div" is alerted
    </script>
</div>

Instead of the this keyword referencing the global object (window) we can make it reference the parentNode of the script element. Here’s the code that makes it work:

(function(){
 
    var scripts = document.getElementsByTagName('script'),
        script, i = 0;
 
    while ( (script = scripts[i++]) ) {
        if ( /:contextual$/.test(script.type) ) {
            (new Function(script.innerHTML)).call(script.parentNode);
        }
    }
 
})();

Take it or leave it! – I’m indifferent either way – yes, it’s obtrusive but you’ve got to admit, contextual JavaScript looks pretty neat!

Satisfy is a development-only jQuery plugin* that you can use to quickly generate HTML for testing/debugging. The idea is that you provide a CSS selector and then the plugin will “satisfy” it by generating an HTML structure in accordance with that selector.

* – UPDATE: This is no longer just a jQuery plugin – as of version 0.2 Satisfy has no dependencies. See the comments for more info.

For example:

jQuery('div a').satisfy();

… would return the following HTML structure:

<div>
    <a></a>
</div>

A more snazzy example:

jQuery('ul li:5 span[innerHTML="link"]').satisfy();

… which would return the following:

<ul>
    <li><span>link</span></li>
    <li><span>link</span></li>
    <li><span>link</span></li>
    <li><span>link</span></li>
    <li><span>link</span></li>
</ul>

(Note: It ignores combinators (+|~|>) and pseudo-classes (:pseudo). It adds support for numerical pseudo-classes (e.g. “:5″) which you can use to specify how many of a particular element you want.)

More information and source available at Github – “satisfy” @ GitHub

I can’t speak for other languages but one of the best things about JavaScript, in my opinion, is the fact that almost everything can be considered as an expression. An expression makes up part of a “statement” and is evaluated to produce a value. Every expression has a “return” value. Consider this:

42

Yup, the number 42 happens to be an expression. This expression is evaluated as the literal number, 42. You can create more complex expressions by using operators. An operator (e.g. the assignment operator, =) expects a number of “operands”.

An “operand” can be thought of as an operator’s argument. For example, what we all know as the “ternary operator” (x?y:z – actually called the “conditional operator”) takes three operands, hence the name “ternary”. It’s the only operator in JavaScript that takes three operands. The assignment operator (=), for example, takes two operands – one on the left and one on the right.

Operators and their corresponding operands can be combined to create interesting and useful expressions. Expressions, as the name suggests, allow you to “express” a piece of logic concisely and efficiently. Much of the logic expressible in a series of if/else statements can also be expressed in a tiny expression.

Precedence & Associativity

Consider the following expression:

+new Date()

There are two operators; the unary plus operator (+) and the new operator. What would you expect this expression to do? Would you expect the + operator to convert the new operator to its numerical form? Would you expect a syntax error to be thrown? Nope? Then what?

The + operator actually “waits” until the new operator resolves its operand; then the + acts on the returned object. So, +new Date() is fundamentally the same as +(new Date()). The order in which operators run is defined by each operator’s “precedence”. The new operator has a higher precedence than the unary plus operator so it’s evaluated first.

Here’s another example:

x = y || z;

The logical OR operator (||) expects two operands, one on the right and one on the left – if the one on the left evaluates to true then it’s returned (z never gets a chance to evaluate). If, however, the one on the left is false then the one on the right is evaluated and returned from the expression. The return value of y || z is assigned to x – this is what you’d expect – but underneath the surface it’s the precedence of each operator in the expresson that defines what happens.

I’ve seen a lot of curious (bordering on horrific) code in my life; and I’d say about half of it was written by me. If you don’t attest to the fact that you once wrote crap code then you’re either a liar or perhaps, have omnipotent powers!

Here’s a relatively small collection of what I see as bad JavaScript practices; in other words – a list of how to write really really ugly JavaScript that will break! I know it’s quite a negative angle to take but it’s easier than writing a post on best practices, plus it gives me a chance to vent! Many of these are things I’ve done in the past; I’ve since discovered the errors in my ways.

Non-constructor identifiers beginning with a capital letter

Variable names should only begin with a capital if they’re pointing to constructor functions. Doug Crockford has more:

There is a convention that all constructor functions are named with an initial capital, and that nothing else is spelled with an initial capital. This gives us a prayer that visual inspection can find a missing new.

Not following conventions will only get you in trouble! So, to be clear, this is all wrong:

var Color = 'red';
var SomeNumber = 234;
var AnArray = [1,2,3];
var Foo = { bar: 123 };
// None of them should start with a capital letter!

Only functions that are constructors should be identified with an initial captial letter, not regular functions. E.g.

/* This is a regular function. */
function sum() {
    var total = 0, i = 0, len = arguments.length;
    for ( ; i < len; ++i ) {
        total += arguments[i];
    }
    return total;
}
 
/* This is a constructor function */
function Widget(innerText, styles) {
    this.innerText = innerText;
    this.cssStyles = styles;
}

Not using the var statement to define variables

Not using the var statement when defining variables for the first time is a very bad idea. These variables will become part of the global scope. This sucks because you won’t get any warning. Not only is it a bad practice but it can have a negative affect on performance, after-all, the further away a scope is the longer it takes to access. So, always use the var statement:

foo = 3; // NO!
var foo = 3; // YES

Prefixing every new variable in a given scope with var

There's no point in having several var statements if you only need one:

var someVar1 = 'a';
var someVar2 = 'b';
var someVar3 = 'c';
 
// Much easier:
var someVar1 = 'a',
    someVar2 = 'b',
    someVar3 = 'c';

Using non-strict comparison operators, and then comparing across different types

There are two classes of comparison operators; those that type-cast (==/!=) when required and those that don't (===/!==). You don't ever want to use the former!

1 == "1"; // true
false == " \n\t "; // true
[[],[]] == true; // true
 
// ... Confused?

See? It's obviously a bad idea! Please only ever use strict-equality comparison operators; they'll check that the two operands are identical, not just "equal":

1 === "1"; // false
false === " \n\t "; // false
[[],[]] === true; // false
 
// Just as expected!

Not "caching" non-varying complex objects

This is vitally important; if you're going to be repeatedly using an object you should name it and save it! A basic example:

If you’ve ever released a JavaScript widget, one which people can include within their site or even if you’re one of those people that has had to copy one of those ugly chunks of code and somehow come to terms with placing it in your previously clean HTML, I’m sure you’ll appreciate a cleaner and less scarring alternative. After all, anything’s got to be better than this:

<div id="widget_133332_g_foobar"></div>
<script>
    widget_133332_v_height = '233px';
    widget_133332_v_width = '200px';
    widget_133332_h_align = true;
    widget_133332_v_align = false;
    widget_133332__debug = false;
    widget_133332_id = 'Foo';
</script>
<script src="http://some-widget-url.com/script?id=widget_133332"></script>

And within script?id=widget_133332 there will be something like this:

document.write('<div id="widget_133332">...</div>');
document.write('<div id="widget_133332_a_sec">...</div>');
document.write('<div id="widget_133332_b_sec">...</div>');
document.write('<div id="widget_133332_c_sec">...</div>');

I’m not complaining; it’s not all that bad. However it could be done better; much better!

I decided to have a proper go at creating one of these. There were a couple of barriers to completion that required some extra work along the way; I’m releasing that extra work as a small stand-alone library that you can use within your 3^rd party scripts. Here’s an example chunk-of-code:

<script src="http://some-service.com/widget.js?id=2323">
({
    width: 200,
    height: 400,
    id: 'my-widget',
    keywords: ['apple', 'orange', 'banana']
})
</script>

Nicer to look at and much easier to use than the status quo! The JSON-like syntax is very easy-to-follow, even if you’ve never seen anything like it. The library used to enable this unique technique is called embedHelper.

Today I’m releasing my first attempt at creating a “selector engine”; it’s called mini! I’m not sure if this really qualifies as a “selector engine” though; it does not entirely support any particular CSS specification; instead, I’ve built it to work with only the most commonly used selectors.

While the work done on engines such as Peppy, Sizzle and Sly (and others…) is commendable the CSS3-support aspect is totally lost on some users. Resig’s post on “Selectors that People Actually Use” attests to this.

mini has been built to support only the most frequently used CSS selectors. If you prefer CSS3-selector wizardry then you won’t like this, at all!

mini supports the following selectors (and variations):

• div
• .example
• body div
• div, p
• div, p, .example
• div p
• div > p
• div.example
• ul .example
• #title
• h1#title
• div #title
• ul.foo > * span

Don’t try and do anything fancy with it! It doesn’t support pseudo-selectors, type selectors or any combinators (other than >).

The entire script weighs in at about 1.5kb (minified) and only 850 bytes (minified and gzipped). It’s quite fast too:

Nicholad Zakas, who wrote this book, recently spoke about JavaScript performance at Google; his presentation was called “Speed Up Your JavaScript” and it’s available to view on Youtube.

In the presentation Nicholas covers areas rarely talked about; he takes a low-level approach by explaining what’s happening behind the scenes when you do something as simple as creating or requesting a variable in JavaScript. It’s not all conjecture though; he has a number of graphs comparing performance across browsers and then details the steps you can take to optimise your code, in order to protect yourself from less-than-satisfactory JavaScript implementations (IE comes to mind).

I’m not obsessed about performance by any means but I do think that the practices shared in his presentation should be followed to the letter. Speed and performance are hot topics on the client-side; our users demand fast and responsive applications/websites.

His advice:

Five key points emerged during the presentation:

• Store out-of-scope variables in local variables.
• Minimise property access.
• Do as little as possible on each iteration of a loop.
• Minimise document reflow by only changing the DOM when absolutely necessary.
• Don’t use inline styles unless you’re animating.

Store out-of-scope variables in local variables

The idea behind this technique is to minimise the amount of work required to get at the variable you want. The further away it is (in the scope chain) the longer it’s going to take to retrieve it. The performance cost is normally marginal but it’s still a good practice. Here’s an example: