Image taken from FAIL Blog.

And, to be honest, I think this epitomizes my view on Vista: it’s something which should never fail, but just did.

Firefox extension

The new Obtrusive JavaScript Checker Firefox extension has been developed from scratch, and as opposed to before, it is now disabled by default, meaning no more auto-run. You have four different ways to call it yourself and run an analysis of the current web page:

Statusbar icon

You now have a small statusbar icon which basically lets you toggle the Obtrusive JavaScript Checker: click it to run, and click it again to hide the results.

Keyboard shortcut

For keyboard shortcut lovers, such as myself, there’s now a key combination to press to invoke it: Ctrl + Option (alt) + Command + O on Macs, and Ctrl + Shift + Alt + O on Windows.

Tools menu

It is also available from the Tools menu as one of the menu items there.

Toolbar button

Another option is to customize your toolbar, and drag the Obtrusive JavaScript Checker toolbar button to your regular toolbar.

Available from addons.mozilla.org

To make it more official and to be able to offer secure and automatic updates, you can now get the Obtrusive JavaScript Checker Firefox extension at addons.mozilla.org. Note: if you have a previous version of it installed, make sure to remove it first. This is a one-time action, and in the future, updates will be pushed out.

Download it!

So, make sure to download the Obtrusive JavaScript Checker Firefox right now, to complement your already existing crucial web developing add-ons!

Alternative versions

• Download Obtrusive JavaScript Checker 0.8 Greasemonkey user script
• Install the Obtrusive JavaScript Checker 0.8 command for Ubiquity

Event handling background

The basic problem is that, as in many other cases, there’s one standardized way of handling events and then there’s a specific one implemented by Microsoft in Internet Explorer.

DOM Level 2 Events Specification

November 13th, November 2000, the Document Object Model (DOM) Level 2 Events Specification was issued. Basically, you use a method called addEventListener to add an event to an element, like this:

document.addEventListener("mousemove", trackMouse, false);
function trackMouse (evt) {
    // The evt parameter is a local event object
}

document.addEventListener("mousemove", function (evt) {
    // Track mouse movement
}, false);

The first parameter is the name of the event, without the “on” prefix, the second is a function reference or anonymous function and the third is capture phase (i.e. if the event should be caught coming down from the element’s parent, or when bubbling up from a child element or itself).

Internet Explorer event implementation

Microsoft decided, a long time ago, to take their own route, and instead use something called attachEvent. The above example would look like this with code adapted to IE:

document.attachEvent("onmousemove", trackMouse);
function trackMouse (evt) {
    // The evt parameter isn't available here, just the
    // one global event object in Internet Explorer
}

document.attachEvent("onmousemove", function (evt) {
    // Track mouse movement
});

The first parameter is the name of the event, but with the “on” prefix, and the second is a function reference or anonymous function.

Microsoft’s event handling is filled with shortcomings, where some of the more serious are:

• Just one global event object, instead of local objects per event.
• When using the attachEvent method, the keyword this in the event handling function refers to the window object, and not the HTML event it actually occurred on.
• No support for capture phase.
• Different syntax, with requiring the “on” prefix for the event in question.

It has actually been so bad, that there was a competition online called the addEvent() recoding contest, to find the most suitable approach to get a common syntax and fixes for the IE bugs. When hobby web developers have to fix the faulty native implementation in a web browser, something is really really wrong.

What happens with Internet Explorer 8?

Every web browser has had proper event handling since about 2001, whereas Microsoft was already back then stuck with their beast of shame, IE 6. Fine, I’ll live with that, However, that they didn’t fix this in IE 7, since it’s one of the major scripting flaws in IE, was beyond me.

However, for IE 8, they said, they were add and repair a lot of JavaScript features. So ok, I waited. And the first IE 8 beta came along and, lo and behold, it even had support for the Selectors API (a working draft from December 2007)! Great, finally, I thought, Internet Explorer is catching up to the rest of the world.

But then I tested it for a while longer, and I soon realized, to my horror, that they had omitted standardized event handling in IE 8 as well! Again! Outrageous!

Microsoft’s take

What’s very interesting, and at the same time scary, is that if you dig a little, there was a bug report for lack of support for addEventListener in Internet Explorer 8, but it was closed with the wonderful motivation “by design”.

By design? Crap, by design? I always thought they knew of their shortcomings and acknowledged them, but were to fix them eventually - however, that statement is rather spitting in the face of developers, openly stating that they know it sucks, and that’s just the way they want it.

Fix it, or don’t release it

I think Microsoft should realize that web developers, although angered, have had a lot of patience with Internet Explorer. Lots of things were missing with IE 7, but people said, “sure, at least they’re trying now”. I felt the same way, they showed that they actually intended to make things better and were about to try to finally deliver a working product.

Lots of famous bloggers and developers, not the very least least JavaScript developers, have supported them, spoken for them and defended them along the way, stating that they’re getting there, one step at a time. But surely, even they must have had enough by now?

When Microsoft intentionally continue to neglect a W3C recommendation from 2000, but implement features from just a draft from 2007, what kind of message do they send out? Personally, I’ve had it.

Fix event handling in Internet Explorer 8, or don’t release it.

Now, you can also install the Obtrusive JavaScript Checker command for Ubiquity, which lets you easily call it after Ubiquity has been summoned. Just start typing something like “obt” and you will be good to go!

Other options

Already available is the Obtrusive JavaScript Checker Greasemonkey user script and the Obtrusive JavaScript Checker Firefox extension.

Support for javascript: links

With this new release, support for javascript: links have been added, i.e. it also points those out and gives them a magenta border. Anyone using this practice should stop immediately, since it’s terrible, both for accessibility and SEO.

Detailed information

Now, when you hover over an element with an inline event, it will show you more information about it:

The same goes for javascript: links:

Summary report

At the bottom left corner of the window, you will be presented with a summary report of the number of javascript: links and inline events in the current web page, and occurrences of each type of inline event summarized. It should be noted that it does this for each frame/iframe.

Downloads

• Download Obtrusive JavaScript Checker Greasemonkey user script
• Download Obtrusive JavaScript Checker Firefox extension
• install the Obtrusive JavaScript Checker command for Ubiquity

Why?

One common and tedious task when improving code is to find inline events in the HTML code, and make sure they are implemented in an unobtrusive fashion instead (more about unobtrusive JavaScript). The web is riddled with inline events, and I strive to make it a better place.

What is Obtrusive JavaScript Checker?

Obtrusive JavaScript Checker is a tool to traverse through all elements in a web page, and when it finds a HTML element with inline events (which is bad, JavaScript should be unobtrusive), it highlights it with a red border.

Availability

It is available both as a Greasemonkey user script and a Firefox extension. The Greasemonkey user script can be customized to only work for certain domains (default is all domains), while the Firefox extension can only be turned on or off.

Downloads

• Download Obtrusive JavaScript Checker Greasemonkey user script
• Download Obtrusive JavaScript Checker Firefox extension

Hold on, whats Ubiquity?

Basically, it’s an extension which allows you to get a small dialog in Firefox, through which you can drastically simplify your workflow and integrate into existing web services and web sites. Just press Alt + Enter (Mac) or Ctrl + Enter (Windows) when in Firefox, and you can just type away with lots of different commands.

In Introducing Ubiquity there’s a video and a lot more information, so I recommend anyone starting there. Example images of using it looks like this:

Styling Ubiquity

Most people starting with Ubiquity will think it should look better, me myself included. I found this styling instruction, but for me it doesn’t seem to work with the latest version, Ubiquity 0.1.2. Have in mind that these are very early versions of Ubiquity, so I’m sure skinning and customizing will be a central part of the future versions.

Introducing rob-search

As an experiment, and also for creating a little Ubiquity blueprint command for myself, I created rob-search. It’s a command to search amongst my blog posts for one or several terms, immediately get the first 5 results in a preview window or pressing Enter to trigger a search and end up in my search results page.

Installing and subscribing to rob-search

Just go to the rob-search web page. If you have Ubiquity installed, you will get a bar at the top asking if you want to subscribe to it. Go through a couple of very hazardous dialogs/steps warning you that I will eat your computer for dinner, and then there you have it!

Let me know what you think!

If you have installed rob-search, please let me know what you think! Did the installation work well, is the command working well etc? Talk to me!

Namespacing?

First, let’s establish that global variables are evil. Got that? Good. An alternative to that is to use an object to be the container for all functionality in a web site, e.g. the customer or product name. Let’s start with a simple example:

var Griffins = {};

I know, amazing, right?

The idea here is that the empty Griffins object you have created will the super object to which everything else will belong. You can now add objects as part of that object, like this:

Griffins.Stewie = {
    evil : true,
    triesToKill : "Mom"
};

and

Griffins.Peter = {
    familyHead : true,
    responsible : false
};

Extending - not necessarily inheriting

As you can see from above, this technique allows you to to use just one global container, and then extend it with different objects and branches depending on desired functionality. The upside of it is that most objects become something like siblings to each other, rather than parent and child objects.

Compared to JavaScript inheritance

The reason I wanted to state that this might pose an alternative to JavaScript inheritance is that, in my experience, inheritance tends to be overused, and developers spend more time overriding functionality inherited from some sort of super object, instead of just focusing on the new object’s features. Basically, inheritance isn’t always the best way to go, whereas namespacing could be the best solution at hand instead.

Namespace assertion

Something to mention here is that if you have your code spread across multiple files, which seems very likely, to make sure the global object exists, you just need to add a little assertion to the top of each file using it, before you try to extend it:

if (typeof Griffins === "undefined") {
    Griffins = {};
}

Griffins.Lois = {
    strangelyHot : true,
    hasWeirdHusband : true
};

This code checks if Griffins is already defined, and if not, it creates a new namespace to add the Lois object to.

Reusage of methods across objects

Now you’re thinking that this approach results in a lot of redundant code, and being completely against DRY principles; on the contrary! The benefit is that from one object’s method, you can choose to just call the method of another, but within the right context. Let’s take a look at these two objects:

Griffins.Chris = {
    brainCapacity : "Low",
    getCapacity : function () {
        return this.brainCapacity;
    }
};

Griffins.Meg = {
    brainCapacity : "Decent",
    lowSelfEsteem : "Low self esteem"
    getCapacity : function () {
        var capacity = Griffins.Chris.getCapacity.apply(this, arguments);
        capacity += " - " + this.lowSelfEsteem;
        return capacity;
    }
};

// Returns "Low"
Griffins.Chris.getCapacity();

// Returns "Decent - Low self esteem"
Griffins.Meg.getCapacity();

What happens here is that the Griffins.Meg object reuses the getCapacity from the Griffins.Chris object, but calls it as itself, through the help of the apply method. I.e. the keyword this in the getCapacity for the Griffins.Chris object will then point to the Griffins.Meg object, getting the property brainCapacity from the correct object.

Evaluating options

So, what I wanted to say with this post is that JavaScript inheritance doesn’t have to be a bad thing, but that sometimes it’s just not the best way to approach a problem. Instead, good namespacing has proven to be very successful and a worthy alternative. Personally, I also think it’s very good for code clarity, instead of chasing up some prototype chains.

Prerequisites

Before reading this article, I strongly recommend reading JavaScript inheritance - how and why and Explaining JavaScript scope and closures first, since many phenomenon below will have their explanation there.

Article objective

After this article, there will be no holy grail of how to code inheritance in JavaScript. I will introduce some common ways, touch on their problems and what one might want to achieve. Most of all, it’s a lesson in very different syntaxes for doing the same thing, and opening your to the wonderful and magical JavaScript world.

At the end of the day, though, it’s up to you to choose what you seem best, or just be inspired by the many options you have to code JavaScript.

First inheritance steps

Let’s start with our first inheritance example, look at the code, an then see what’s good respectively not so good with it.

Inheritance from a regular object

I thought we’d start out easy, with inheriting from a regular object:

// Basic object
var Base = {

	// Public properties and methods
	dayName : "Tuesday",

	day : this.dayName,

	getDay : function () {
		return this.dayName;
	},

	setDay : function (newDayName) {
		this.dayName = newDayName;
	}
};

Cool so far? Good. Let’s create an object which inherits from our basic Base object:

// Using new Base() is not an option,
// since it isn't a constructor
Sub.prototype = Base;
function Sub () {
	// Constructor
};

A test run

var a = new Sub();
// Returns "Tuesday"
alert(a.getDay());

var b = new Sub();
// Returns "Tuesday"
alert(b.getDay());

// Sets dayName to "Wednesday"
a.setDay("Wednesday");

// Returns "Wednesday"
alert(a.getDay());

// Returns "Tuesday"
alert(b.getDay());

// Returns undefined
alert(b.day);

Everything above is probably what you expected, except the last one that returned undefined. The problem is that the Base object tries to set a property while it’s executing, and then it doesn’t have any internal reference. Using a method instead for the day property would be a possibility to make it work:

day : function () {
	return this.dayName;
}

What’s good

As mentioned in the comment, you can point out Base object as the ancestor to inherit its prototype from, but since Base isn’t a real constructor, you cannot call it with the new keyword. Basically, this means that the Base constructor isn’t run, until an instance of the Sub object is being created.

This can be a good thing, since you might not want any unnecessary code to be run in the constructor, before it’s actually time. Personally, I never have anything important in the constructor, but put in an init method instead, so I can completely control when it is being invoked.

Not so good

What’s less good here is that all properties and methods are declared inline of the Base object, meaning you can’t utilize the prototype behavior. Also, there’s no way to have any private variables.

Private variables/members and prototype

Something a lot of people ask about is if it’s possible to have private variables in an object, and then being able to access them through any prototype method. The answer is, unfortunately, no (kind of). For private methods, however, there is an opportunity which I will go into later below.

Starting the syntax circus

From here on, I will present three different syntax alternatives to basically achieve the same results, but in very different fashions. It will also show the problems with private variables and prototype, and how it does work with private methods.

Basic Prototype inheritance

First out is regular prototype inheritance, where one private variable and one private method are declared:

// Basic Prototype inheritance
function Base () {

	// Private variable
	var dayName = "Tuesday";

	// Private method
	function getPrivateDayName () {
		return dayName;
	}

	// Public properties and methods
	this.day = dayName;

	this.getDay = function () {
		return getPrivateDayName();
	};

	this.setDay = function (newDayName) {
		dayName = newDayName;
	};
};

Sub.prototype = new Base;
function Sub () {
	// Constructor
};

What’s good

Simple syntax and everything reachable from within the constructor.

Not so good

To be able to access the private variable and private method, everything needs to be within the constructor, instead of through prototype assignment. Not a recommendable approach.

Yahoo JavaScript Module Pattern

I’ve mentioned it before, but my personal favorite when it comes to singleton objects is the Yahoo JavaScript Module Pattern. With the prospect of prototype inheritance, you can also use it as the prototype ancestor object for any sub object you are interested in creating. Basically, like this:

// Yahoo JavaScript Module Pattern
var Base = function () {

	// Private variable
	var dayName = "Tuesday";

	// Private method
	var getPrivateDayName = function () {
		return dayName;
	}

	// Public properties and methods
	return {

		day : dayName,

		getDay : function () {
			return getPrivateDayName.call(this);
		},

		setDay : function (newDayName) {
			dayName = newDayName;
		}
	};
}();

// Using new Base() is not an option,
// since it isn't a constructor
Sub.prototype = Base;
function Sub () {
	// Constructor
};

What’s good

Nice code structure, good separation between private and public properties and methods.

Not so good

It isn’t a “true” constructor, so you can’t call it with new. Also, all public properties and methods are inline in the object, so it can’t utilize the recommended prototype approach.

Closure-created constructor

This piece of code creates a closure where you have the constructor, private variables and methods and assigns prototype properties and methods to the object. It then return the actual constructor object, so the next time it is run it’s behaving just like a normal constructor, while the closure makes sure all methods and values are still accessible.

By far the coolest code, if you ask me.

// Closure-created constructor
var Base = (function () {

	// Constructor
	function Base () {

	}

	// Private variable
	var dayName = "Tuesday";

	// Private method
	function getPrivateDayName () {
		return dayName;
	}

	// Public properties and methods
	Base.prototype.day = dayName;
	Base.prototype.getDay = function () {
		return getPrivateDayName.call(this);
	};

	Base.prototype.setDay = function (newDayName) {
		dayName = newDayName;
	};

	return Base;
})();

Sub.prototype = new Base;
function Sub () {
	// Constructor
};

What’s good

This code uses a closure to have a constructor initiated, with complete control over prototype properties and methods, which in turn have access to private variables and methods. Its structure, if you ask me, is very nice, because you have the constructor and the properties and methods within the same code block, giving it more of a togetherness.

Not so good

The only real downside is that the private variable is limited to the scope, hence being the same for all instances. Also, it’s a bit weird to have private variables outside of the constructor.

The code execution results for all three approaches

var a = new Sub();
// Returns "Tuesday"
alert(a.getDay());

var b = new Sub();
// Returns "Tuesday"
alert(b.getDay());

// Sets dayName to "Wednesday"
a.setDay("Wednesday");

// Returns "Wednesday"
alert(a.getDay());

// Returns "Wednesday"
alert(b.getDay());

// Returns "Tuesday"
alert(b.day);

But why? The problem is that the scope each approach uses to create a private variable, which works fine, is also the closure, in action, that results in if you change a private variable for one object instance, it is being changed for all. I.e. it’s more like a private static property, than an actual private variable.

So, if you want to have something private, more like a non-public constant, any of the above approaches is good, but not for actual private variables. Private variables only work really well with singleton objects in JavaScript.

In terms of private methods, however, it works swell! You can hide away helper methods from the public eye, and then utilize it from your prototyped code.

Download the complete code

To make it easier for you, I’ve put all four code approaches in the same JavaScript file, so you can download the inheritance demo JavaScript file and play around with the code, tweak some settings, and hopefully, at the end of the day, be a more enlightened JavaScript programmer.

Wrapping up

As you can see, JavaScript offers many ways to do the same thing with code, and different solutions have different advantages and disadvantages. I also think an important lesson to learn is that there’s a difference between code doing/delivering the expected results and optimal code best for runtime, execution and reusage.

Feedback

Please let me know what you thought of this experiment! I wanted to mess with your heads a little, while also opening up your mind to alternative solutions. If anything’s wrong or or not as good as it can be with the code, or if you have any solutions to the problems posed above, don’t hesitate to let me know!

Why semicolon insertion?

Unfortunately, semicolons are optional in JavaScript, which leads to developers being sloppy, using them in some places, while omitting them elsewhere. “Luckily”, JavaScript interpreters take this into account, and at runtime, insert semicolons where it thinks it should be one.

Good and bad code style examples

So, how is this a problem? Let’s start by taking a look at the below code:

// Good
return {
	javascript : "fantastic"
};

// Bad!
return
{
	javascript : "fantastic"
};

The problem

So, I’m sure some of you wonder what the hell’s wrong with having the opening curly bracket on a new line? You love that coding style and it all becomes clearer. The answer is semicolon insertion. The bad code is interpreted like this:

return; // Semicolon inserted, believing the statement has finished. Returns undefined
{ // Considered to be an anonymous block, doing nothing
	javascript : "fantastic"
};// Semicolon interpreted as an empty dummy line and moved down

My advice

Since it does matter where you put the curly brackets, my strong recommendation is to use the opening one at the end of the line, preceded by other code. Also, make sure to always put semicolons in your code, to avoid potential problems.

Acknowledgements

I first saw this lovely example being presented by Douglas Crockford at @media AJAX 2007 (my report), and my pal Remy presented it in his blog. I just wanted to re-iterate the point here, since a lot of people doesn’t seem to know about semicolon insertion.

The presentations

Shifting your site into the next gear

In this session Chris is showing how you can speed up your web sites, what issues to avoid, what of the information out there is really applicable to you and what little things you can change to get a great impact. As examples we’ll cover lazy loading and progressive enhancement that delivers faster and makes end users happy.

Playing with the web

In this session Chris is going to show tools and ideas that allow you to quickly prototype changes in web sites, get to information that is not offered publicly and re-hash that information into something useful. As examples we’ll be looking at creating a currency converter, translating and detecting language and show how we can change and distribute the change of a web site without touching the server.

Location and sponsorship

This Geek Meet will take place at our kind sponsors Creuna December 4th 18.00, at Kungsholmsgatan 23 (a map to the location).

Beers, other assorted drinks and about as much pizza as you can eat will be offered to the attendants.

Sign up now - limited seating!

Due to a very high interest in this talk, there will be a limited seating of 70 slots. The first 70 who sign up through a comment below will get them. You can only sign-up yourself, i.e. no comments like: “Me and my 10 friends might drop in”. Signing up is binding.

Live broadcast

For those not being able to attend, this event will also be broadcasted live through the Internet starting at December 4th 18.30 CET at http://geekmeet.creuna.se/. The first session is estimated to start at 18.30 CET, and the second at 21.00 CET.

Sign up now!

No one knows what it’s like
To be the bad browser
To be the sad browser
Behind blue Es

No one knows what it’s like
To be hated
To be fated
To telling only lies

But my dreams
They aren’t as :empty
As my rendering seems to be

I have hours, only lonely
My love is vengeance
That’s never free

No one knows what it’s like
To feel these feelings
Like I do
And I blame you

No one bites back as hard
On their anger
None of my pain and woe
Can show through (hasLayout issues?)

But my dreams
They aren’t as :empty
As my rendering seems to be

I have add-ons, only properiatary
My love is vengeance
That’s never free

When my CSS display clenches, crack it open
Before I drown it in my invisible-content pool
When I do right, tell me some bad news
Before I laugh and act like a proper tool

If I swallow anything evil
Put your finger down my throat
If I shiver, please give me a blanket
Keep me warm, let me wear your coat

No one knows what it’s like
To be the bad browser
To be the sad browser
Behind blue Es

Original lyrics by The Who: Behind Blue Eyes

IE logo with pins graciously borrowed from Make Your Own Internet Explorer Voodoo Doll – A Step by Step Guide, originally from Teresa’s DeviantArt forum post.

Background

For the developers coming from a heavy object-oriented background, defining and using these sort of members is key to all code being written. Not really so when you work with JavaScript, but I thought I’d explain how to use that sort of approach with JavaScript to make your code more versatile.

Putting together our object

We will put together a constructor object, of which you can create new instances by using the new keyword. Let’s start with an empty one, to get a hang of it:

// Constructor
function Kid (name) {
	// Empty, for now
}

Now you can create as many kid objects you want, in this fashion:

var kenny = new Kid("Kenny");

Adding a private property

As we learned in the JavaScript scope and closures article, by declaring a variable within a function, it is only available from within there. So, if we want a private property of the Kid object, we do it like this:

// Constructor
function Kid (name) {
	// Private
	var idol = "Paris Hilton";
}

The idol property will only be available for the code inside the Kid function/object.

Adding a privileged method

A privileged method is a method having access to private properties, but at the same time publicly exposing itself (in JavaScript, also due to JavaScript scope and closures). You can delete or replace a privileged method, but you cannot alter its contents. I.e. this privileged method returns the value of a private property:

// Constructor
function Kid (name) {
	// Private
	var idol = "Paris Hilton";

	// Privileged
	this.getIdol = function () {
		return idol;
	};
}

Adding a public property and a public method

Now that we have private and privileged members out of the way, let’s look at the very basic nature of public properties and methods:

// Constructor
function Kid (name) {
	// Public
	this.name = name;
	this.getName = function () {
		return this.name;
	};
}

The property name is publicly available for any call, just like the getName method is.

// Constructor
function Kid (name) {
	// Public
	this.name = name;
}
Kid.prototype.getName = function () {
	return this.name;
};

Adding a static property

A static member is shared by all instances of the class as well as the class itself (i.e. the Kid object), but it is only stored in one place. This means that its value is not inherited down to the object’s instances:

// Constructor
function Kid (name) {
	// Constructor code
}

// Static property
Kid.town = "South Park";

Our complete object

Let’s take a look at our complete object, before we try accessing its properties and methods:

// Constructor
function Kid (name) {
	// Private
	var idol = "Paris Hilton";

	// Privileged
	this.getIdol = function () {
		return idol;
	};

	// Public
	this.name = name;
}

// Public
Kid.prototype.getName = function () {
	return this.name;
};

// Static property
Kid.town = "South Park";

Creating an instance and checking access

Now, finally, it’s time to test how these different approaches work in practice. We start by creating an instance of the Kid object, and then test what different values we get back. The tests and their results are:

 // Create a new instance

var cartman = new Kid("Cartman");

// Access private property
cartman.idol; // undefined

// Access privileged method
cartman.getIdol(); // "Paris Hilton"

// Access public property
cartman.name; // "Cartman"

// Access public method
cartman.getName(); // "Cartman"

// Access static property on an instance
cartman.town; // undefined

// Access static property on the constructor object
Kid.town; // "South Park"

Conclusion

I hope this has been a good way to pique your curiosity about your different options when it comes to objects and its members! Also, for those new to JavaScript, but experienced in object-oriented programming with other languages, hopefully this answered some of the questions you might have had.

Now go create objects!

Emilia and Filippa have a number of dolls/action figures from the Pippi Longstocking world (why the hell do I start thinking about The Big Lebowski and Log Jammin’ when I write that? ).

Anyway, Filippa has decided to give them titles of their own. Here goes:

Our given names

“Mom”

So, apparently Filippa views mom as some extremely uptight middle-aged lady (if not older), who seems more boring than what anyone could ever fathom is possible. Personally, I thought it was hilarious first time she pointed to Prussiluskan (the character’s name) and sweetly said: “Mom”.

However, Fredrika doesn’t approve when I call Filippa’s spontaneous and completely authentic recognition uncanny…

“Dad”

Ok, as you can imagine, I didn’t enjoy this one as much. It seems Filippa’s take of me is that I’m acting like a loud fat police, where the outfit resembles some fascist just a little bit too much. Seriously, Filippa, come on!

Our own takes

Mom’s own perception

This is probably Fredrika’s own view of herself: a young, happy girl, still unspoiled by the world. While I wouldn’t mind seeing Fredrika in such a dress, I wouldn’t dare to state that it’s a realistic self-image.

Dad’s own perception

Ok, now it’s better. We all know (or rather deliriously believe) that I am the cop of our family, being the stern guy. But I’m not fat, dammit!!! I’M NOT FAT!

Background

There are a number of articles and blog posts out there trying to explain scope and closures, but overall I’d say that a majority of them aren’t crystal-clear. Besides, a number of them take for granted that everyone has developed in about 15 other languages before, while my experience is that a lot of people writing JavaScript come from a HTML and CSS background, instead of C and Java.

Therefore, my humble goal with this article is for everyone to finally grasp what scope and closures are, how they works, and especially how you can benefit from them. You do need to understand the basic concepts of variables and functions before reading this.

Scope

Scope refers to where variables and functions are accessible, and in what context it is being executed. Basically, a variable or function can be defined in a global or local scope. Variables have so-called function scope, and functions have the same scope as variables.

Global scope

When something is global means that it is accessible from anywhere in your code. Take this for example:

var monkey = "Gorilla";

function greetVisitor () {
	return alert("Hello dear blog reader!");
}

If that code was being run in a web browser, the function scope would be window, thus making it available to everything running in that web browser window.

Local scope

As opposed to the global scope, the local scope is when something is just defined and accessible in a certain part of the code, like a function. For instance;

function talkDirty () {
	var saying = "Oh, you little VB lover, you";
	return alert(saying);
}
alert(saying); // Throws an error

If you take a look at the code above, the variable saying is only available within the talkDirty function. Outside of it it isn’t defined at all. Note of caution: if you were to declare saying without the var keyword preceding it, it would automatically become a global variable.

What this also means is that if you have nested functions, the inner function will have access to the containing functions variables and functions:

function saveName (firstName) {
	function capitalizeName () {
		return firstName.toUpperCase();
	}
	var capitalized = capitalizeName();
	return capitalized;
}
alert(saveName("Robert")); // Returns "ROBERT"

As you just saw, the inner function capitalizeName didn’t need any parameter sent in, but had complete access to the parameter firstName in the outer saveName function. For clarity, let’s take another example:

function siblings () {
	var siblings = ["John", "Liza", "Peter"];
	function siblingCount () {
		var siblingsLength = siblings.length;
		return siblingsLength;
	}
	function joinSiblingNames () {
		return "I have " + siblingCount() + " siblings:\n\n" + siblings.join("\n");
	}
	return joinSiblingNames();
}
alert(siblings()); // Outputs "I have 3 siblings: John Liza Peter"

As you just saw, both inner functions have access to the siblings array in the containing function, and each inner function have access to the other inner functions on the same level (in this case, joinSiblingNames can access siblingCount). However, the variable siblingsLength in the siblingCount is only available within that function, i.e. that scope.

Closures

Now when you hopefully have gotten a better grasp of what scope is, let’s add closures to the mix. Closures are expressions, usually functions, which can work with variables set within a certain context. Or, to try and make it easier, inner functions referring to local variables of its outer function create closures. For instance:

function add (x) {
	return function (y) {
		return x + y;
	};
}
var add5 = add(5);
var no8 = add5(3);
alert(no8); // Returns 8

Whoa, whoa! What just happened? Let’s break it down:

1. When the add function is called, it returns a function.
2. That function closes the context and remembers what the parameter x was at exactly that time (i.e. 5 in the code above)
3. When the result of calling the add function is assigned to the variable add5, it will always know what x was when it was initially created.
4. The add5 variable above refers to a function which will always add the value 5 to what is being sent in.
5. That means when add5 is called with a value of 3, it will add 5 together with 3, and return 8.

So, in the world of JavaScript, the add5 function actually looks like this in reality:

function add5 (y) {
	return 5 + y;
}

The infamous loop problem

How many times have you created some sort of loop where you wanted to assign the value of i in some way, e.g. to an element, and found out it just returned the last value i had?

Incorrect reference

Let’s take a look at this faulty code, which creates 5 a elements, adds the value of i as a text to each element and an onclick which is expected to alert the value of i for that link, i.e. the same value as in the a element’s text. It then appends them to your document body:

function addLinks () {
	for (var i=0, link; i<5; i++) {
		link = document.createElement("a");
		link.innerHTML = "Link " + i;
		link.onclick = function () {
			alert(i);
		};
		document.body.appendChild(link);
	}
}
window.onload = addLinks;

Each a element gets the correct text, i.e. “Link 0″, “Link 1″ and so on. But whichever link you click, it alerts the number “5″. Oh my God, why? The reason for this is that the variable i get its value increased with 1 for each iteration of the loop, and since the onclick event isn’t being executed, just applied to the a element, it adds up.

Therefore, the loop continues until i is 5, which is the last value of i before the function addLinks exits. Then, whenever the onclick event is actually being triggered, it takes the last value of i.

Working reference

What you want to do instead is create a closure, so that when you apply the value of i to the onclick event of the a element, it gets the exact value of i at just that moment in time. Like this:

function addLinks () {
	for (var i=0, link; i<5; i++) {
		link = document.createElement("a");
		link.innerHTML = "Link " + i;
		link.onclick = function (num) {
			return function () {
				alert(num);
			};
		}(i);
		document.body.appendChild(link);
	}
}
window.onload = addLinks;

With this code, if you click the first a element it will alert “0″, the second “1″ etc; just what you probably expected with the first code I showed you to do. The solution here is that the inner function of what’s applied to the onclick event create a closure where it references the parameter num, i.e. what the i variable is at just that time.

That function then closes with that value safely tucked away, and can then return its corresponding number when the onclick event is being called.

Self-invoking functions

Self-invoking functions are functions who execute immediately, and create their own closure. Take a look at this:

(function () {
	var dog = "German Shepherd";
	alert(dog);
})();
alert(dog); // Returns undefined

Ok, so the dog variable was only available within that context. Big deal, man, hidden dogs… But, my friends, this is where it becomes really interesting! It solved our problem with the loop above, and it is also the base for the Yahoo JavaScript Module Pattern.

Yahoo JavaScript Module Pattern

The gist of the pattern is that it uses a self-invoking function to create a closure, hence making it possible to have private and public properties and methods. A simple example:

var person = function () {
	// Private
	var name = "Robert";
	return {
		getName : function () {
			return name;
		},
		setName : function (newName) {
			name = newName;
		}
	};
}();
alert(person.name); // Undefined
alert(person.getName()); // "Robert"
person.setName("Robert Nyman");
alert(person.getName()); // "Robert Nyman"

The beauty of this is that you now can decide on your own what will be publicly visible for your object (and can be overwritten), and what is private and no one can access nor alter. The variable name above is hidden outside the context of the function, but accessible from the returned getName respectively setName functions, since they create closures where they have a reference to the name variable.

Conclusion

My sincere hope is that after reading this, novice or experienced programmer, you have gotten a clear view of how scope and closures actually work in JavaScript. Questions and feedback are very welcome, and if any input is deemed important enough, I will update this article with it.

Happy coding!

The history

When we were working together back in 2000, it was the good ol’ days for IT and we were hired as consultants for one of the larger Internet consultancy companies in Stockholm. For instance, when the company was introduced to the stock market, we were standing on a gargantuan balcony in central Stockholm, drinking champagne and looking down at the mob in the streets…

In our project, all team members had about the same music taste, so we constantly listened to some good rock and heavy metal while developing the extranet we were working on. It was a good group of people, and we had some nice times.

Fast forward to today(-ish)

We had lunch at a local place in Stockholm, where we talked about our family situations and what had happened since the IT boom. After the initial “how are things now 8 years later”-phase, we got to talking about our currently professional roles and what we were doing. Before I got to say anything, he tilted his head a little and said:

Please don’t tell me you still work with JavaScript

While he’s a good guy, naturally, I wasn’t too happy about that he either insinuated that it wasn’t “proper” developing, or that by now, I should’ve moved to something more sturdy. Knowing that he’s very nice, he probably meant less harm than I make it out to be, but I was still a bit dumbfounded.

The web and the future

To be honest, I couldn’t be more excited by working with JavaScript. In these times and age, JavaScript is used almost everywhere for interaction coding, and with the AJAX revolution and the extremely wide-spread JavaScript libraries, what better coding place is there to be in?

Apparently people have taken the rapid and dynamic developing JavaScript offers to their hearts, and with web browser vendors (at the least the serious ones) implementing crazy-fast rendering engines, JavaScript will be around for a long long time. Therefore, I’m very happy.

Do you work with JavaScript, and how do you feel about it?

Record company deals

Spotify has signed groundbreaking deals with companies such as Universal Music Group, Sony, BMG, EMI Music, Warner Music Group, Merlin, The Orchard and Bonnier Amigo. The result of this lets the service excel into a fantastic while also legal alternative to illegal downloading and file-sharing.

The different account types are such lucrative deals, I predict a lot of people will start paying for quality instead of downloading something sub-par through a probably untrusted source with their nearest BitTorrent service.

Spotify account options

Basically, there are three types of accounts you can have with Spotify:

Free account

This is sponsored by ads, and is for the moment only available through invites, and for the UK, France, Italy, Spain, Sweden and Norway.

Day pass, 24 h

Costs respectively 1€ / £1 / 9SEK. It gives you free access without advertisements for 24 hours, and a great first step if you’re curious about the service.

Premium, monthly/yearly

The Premium account is what you want if you get hooked to Spotify (and you will ). It costs 9€ / £9 / 99SEK for a month, or 99€ / £99 / 999SEK for a year. Currently available in the UK, Germany, France, Italy, Spain, Sweden, Finland and Norway

So, to sum it up: due to rights and contracts at the moment, currently free invite-accounts are only available to certain European countries, while the Day-pass and Premium services are available in a few more. However, from what I hear, it will most likely be available to most parts of the world within the near future, so stay tuned!

10 more invites

As a special launch bonus, I can offer the first 10 commenters asking for it an invite to the free Spotify service (invite will be sent to the e-mail address you write in the comment).

Now, I’d recommend virtually anyone without an invite to try the Spotify Day pass. Within 24 hours, you’ll swear by it, mark my words.

Related reading

• The Spotify party
• Spotify blows me away!

The prototype way

The way inheritance works in JavaScript is that it is prototype-, instead of class-based. For instance, take a look at this:

function Being () {
	this.living = true;
}
Being.prototype.breathes = function () {
	return true;
};

An object which inherits Being:

Robert.prototype = new Being;
function Robert () {
	this.blogs = true;
}
Robert.prototype.getsBored = function () {
	return "You betcha";
};

So, basically, if we create a new instance of the Robert object and call some of its methods, the result would be:

// Create an instance of the Robert object
var me = new Robert();

/*
	Returns "You betcha" as it's a method
	belonging to the Robert object
*/
me.getsBored();

/*
	Returns true. Since the Robert object
	doesn't have a breathes method of
	its own, it goes back in the
	prototype chain to its parent
	object, Being, and finds the
	method there
*/
me.breathes();

Calling a parent’s method

If you want to call a super method of the method currently being executed, i.e. if the same method also exists on the parent object, this is how it would have been done the prototype way:

Robert.prototype.getsBored = function () {
	/*
		Basically, you need to know the name of
		the object and the method name as well.
		Then call it in context
	*/
	Being.prototype.getsBored.call(this);
	return "You betcha";
};

Just to point it out, you could also write: this.constructor.prototype.getsBored.call(this);. The reason for this is that this.constructor points to the main constructor of the object, hence the Being object in this case.

Read more about prototype inheritance

For a more thorough explanation, read about Prototypes and Inheritance - JavaScript: The Definitive Guide.

People mimicking class-based inheritance

A lot of developers, however, come from a class-based inheritance world and either prefer that syntax or just refrain from wanting to use different syntaxes/approaches for different languages. A result of this has been a number of implementations of a more class-based nature in JavaScript, of which these are some of the more well-known ones:

• Simple JavaScript Inheritance - John Resig
• A Base Class for JavaScript Inheritance - Dean Edwards
• Defining classes and inheritance - Prototype JavaScript Framework

I won’t dig into details into these, but the above code would look something like this with John Resig’s implementation:

var Being = Class.extend({
	living : true,
	breathes : function () {
		return true;
	}
});

var Robert = Being.extend({
	blogs : true,
	getsBored : function () {
		return "You betcha";
	}
});

var me = new Robert();
me.getsBored(); // Returns "You betcha"
me.breathes(); // Returns true

Calling a parent’s method, super-style

If both the Being object and the Robert object were to have a getsBored method, you’d have the option to call the one belonging to the Being object in a very easy manner:

var Robert = Being.extend({
	blogs : true,
	getsBored : function () {
		// This is the syntax to call a super method
		this._super();
		return "You betcha";
	}
});

The way Robert (not the object) swings

I’d thought I’d share my take on the necessity of inheritance overall, and what syntax or solution to use when needed and justified.

Is there really a huge need for super calls?

First, I’d say that while it’s all nice and fine with super method calls, in my experience at least, there have been extremely few, if any, real live cases where I have felt a strong need, a mandatory path to go, with super relations. And apparently I’m not alone with this opinion. Douglas Crockford states:

I have been writing JavaScript for 8 years now, and I have never once found need to use an uber function. The super idea is fairly important in the classical pattern, but it appears to be unnecessary in the prototypal and functional patterns. I now see my early attempts to support the classical model in JavaScript as a mistake.

What syntax to use?

However, for those cases you need some sort of inheritance, what syntax should you use? Personally, I’d say that while I’m somewhat attracted to the class-syntax-like implementations, I prefer using the prototype approach for a number of reasons:

• It’s native, i.e. no dependencies on other code.
• Freedom of style and version, i.e. if it depended on other code, it would also depend on version of and implementor of that code.
• Easy readability. I’m sure some of you would want to contradict me, but personally I think the prototype syntax is very easy to look at and understand.
• Leaving the code to someone else. If you have used a native JavaScript solution, everyone knowing JavaScript will immediately understand it and be able to maintain or extend it. Not the same thing with custom code.

Is there a need for inheritance?

However, I would like to even take it one step further than above. It seems like a number of people overuse inheritance ever so often, ending up in spending most time overriding properties and methods in an object’s parent object, than actually using the parent object as an advantage.

For me, I tend to use the Yahoo JavaScript Module Pattern almost all of the time, and I’m quite happy with it! I ported DOMAssistant to it as well, and it’s a move I don’t regret.

The downside of the pattern is that you can’t (not easily, at least), create several instances of the same object. However, the need for this comes very seldom for me, and when it does, I prefer having used a good namespace I can extend (perhaps based on a custom method in the main object), instead of regular, or “true”, inheritance. A good example of my approach is How to create a plugin for DOMAssistant.

Embrace and join us!

I would humbly like to ask of you to embrace JavaScript. Don’t try to make it into Java, C or any other language. Learn to love it and its dynamic, loose and prototypical nature, and go with the flow. When you stop fighting is when you truly understand how wonderful JavaScript is!

The number of invites are limited, and I have 40 invites to give away to you at this moment! To be as fair as possible, each commenter gets one invite, and the first 40 commenters will get an invite.

Make sure to give me your correct e-mail address in your comment information, because this is the address the invite will be sent to. No need to write e-mail addresses in the comment itself, don’t give spammers that joy…

So, fire away! I definitely guarantee this is the most exciting invite you’ve got since Gmail!

Related reading

• The Spotify party
• Spotify blows me away!

Prologue

If you’re expecting more information about the Spotify service, I unfortunately need to quench your hopes right now; this post is just about the party (although I did find out some things about Spotify, which makes its future even more promising!). At the time, Spotify is only available through invites, and sorry, I don’t have any invites to give away.

The party

I had been feeling very low all day, since I seemed to have caught some variation of the flu. Therefore, I just dragged my feet around, just wanted to sleep, but still, I knew I couldn’t miss an event such as the Spotify party. So, I collected myself, took forever to shower and shave, and decided to take the car to the event (since there was no chance I’d survive either of drinking and commuting).

The party took place at Berns, and when I got there at about 21.00, it was almost already filled to the brim.

Photo courtesy of Spotify Party

Drink tickets

At the door, I got a couple of drink tickets to enjoy myself with. “Drink tickets”, perhaps a few people from the US might ask.

Over here, all drinks are free at the really good parties.

Well, here in Sweden drinks costs about the same amount of money your banks seem to be losing every day, and people here drink a lot. So, if any company would have a party of this magnitude, with completely free drinks for everyone all night, it would soon go into bankruptcy. Yeah, really.

Except for the drink tickets, though, there were some small booze bottles available for the daring ones…

Clinging

Having just one invite, going alone, I drifted around, back and forth, desperately looking for someone I knew. Being IT people there, I was sure I’d stumble upon someone, sooner or later.

The only people I did find was two people I know at Spotify: Andreas Ehn and Magnus Hult. While they’re both very nice, I didn’t want to harass them for too long, mainly out of two very obvious reasons, really: it was their event and tons of people wanted to talk to them, and also that I was probably the least fun and interesting company available.

Guitar Hero

Oh, how I loathe Guitar Hero. I hate that game. Or really, there’s nothing wrong with the game, per se, and it’s somewhat fun playing (although I prefer to play a real guitar). But I really, strongly wish that I will, in the foreseeable future, attend a party where Guitar Hero isn’t present. Why? Because while it’s ok playing, it’s dead boring watching and standing around.

However, since I was practically alone, me and my glass of Coke (the drink) had to find some place to stand and hang out, since it was getting tiresome walking around, trying to look busy and/or like I was looking intensely for someone.

Photo courtesy of Spotify party - Guitar Hero

So what did I do? Together with a number of Guitar Hero deadheads, I stood watching people playing Guitar Hero like it was my favorite interest in the whole wide world…

Call for help

After having been at the party for about an hour, I started to feel a bit lonely, and called Emil, since I knew him and Lady S. (his squaw-to-be?) were to attend. Luckily, they were on their way there, so I exhaled and felt a bit better.

You’re not alone

Kept on watching Guitar Hero (yay), and while doing that I felt a tap on my shoulder. It was my pal Jim, who I didn’t even know was going! Apparently, his neighbour was one of the artists performing later that night, so he and his friend Adam had gotten tickets to the event as well.

Jim and Adam went to leave their jackets, and while doing that, Emil and Lady S. popped in! Finally, I knew loads of people!

Performances

We first mingled at the bar for quite some time, and when the performances started, we moved into the large party room/concert venue and watched. There were tons of people now at the party, and it really took some effort to get anywhere amongst the masses, not to mention the ridiculously long lines to the bathroom.

When I couldn’t bother standing in one of the lines, I went into an adjacent room looking for another bathroom in another section, but found none. When I went back, two guards were standing where I had initially walked into the room, and stared furiously at me. The conversation went something like this:

- Are you in a band?
- Huh?
- Are you in a band?
- No (thinking: why would I be in a band?).
- So what the hell were you doing in there?
- Looking for a bathroom.

No more replies, except for some possible grunting, but with looks filled with hate.

Really, they took the pretty old, fairly short, completely sober and somewhat sick-from-a-flu guy to pick a fight with? Jeez…

I mean, I have bad days at work too, but the intern isn’t the first one in the line of fire. Or… well, anyway, moving on…

Backstage

After the performance of Jim’s neighbour, he got an SMS from him, wanting to meet. After a cat-and-mouse chase and some very vague descriptions, we finally found our way backstage (no guards there, why would there be, they were busy guarding potential bathroom-queue elopers). After following a maze of fire-stairs, corridors and what-not, we eventually got to the backstage area.

Something I found fantastic, since there were nice couches to sit in, free coke to drink (and naturally, alcohol for those physically fit for it) and free candy in bowls for anyone to eat. Given how tired and worn I felt at this moment, it was heaven to me! No being pushed every other second by over-refreshed people, no overpriced drinks (I was out of drink tickets at this time), and no loud music, so we could actually talk.

The conversation

We were back there for about an hour, and occasionally now and then some more people would drop in. When we introduced ourselves to the “new people”, an interesting conversation took place, when Jim’s friend Adam introduced himself:

- Hi, I’m Adam.
- Are you Jewish?
- No.
- Oh, ok. It’s cool, either way.

Being actually there, let me be the first to point out that it was totally clear that it wasn’t a racist question, but rather an attempt to find a topic to start a conversation with. It did sound both funny and weird when it came out, though.

I think this is due to that, as far as I know, to begin with we don’t have that many people with a Jewish heritage in Sweden, and second, we don’t really care where people are from, so the word Jewish is just very seldomly mentioned here.

Going home

After some people was thinking that it was a bit lame/low-key backstage (still heaven for me ), they started to play some music and bringing some life to it. Something I would’ve liked under usual circumstances, but now I was just way too tired. I decided to leave them to their fun and avoid ruining their party out of being plain boring, and instead started my journey home.

Related reading

• Spotify - get you own invite now!
• Spotify blows me away!