James McParlane's Blog

I want my children to grow up in a world when coding in JavaScript does not result in a fistfight.

Brendan Eich may have intended Arrays to be only numeric, but the reality is they do more, and people have explored and used them to the fullest extent.

It is arguable that people pushing the JavaScript envelope in this way have made Web 2.0 viable.

I won’t blame people for being creative.

But now we have libraries that can’t co-exist, libraries that come embedded with insoluble philosophies. 134 Ajax libraries and counting. Oh the huge manatee!

We have to lay down some ground rules or JavaScript is going bring some serious issues to the next generation of ‘Internet Applications’.

Its a little like driving and everyone agreeing on the rules of the road. If we all do this, things will get easier. Its a form of best practice. Its not arbitrary. Its a realpolitik compromise that allows everyone to get most of what they want. Some people want to extend objects for reasons of syntax and performance, others want to keep them pristine to allow libraries to inter-operate.

I propose the following rules to allow us to move forward.

#1 – Don’t use Object.prototype to extend the base ‘Object’.

Feel free to play with any other builtin type. ‘Array’, ‘Number’, ‘Boolean’, ‘Date’, ‘Regex’,….  but leave ‘Object’ alone.

Dean Edwards sums it up best.

“Extending native objects is a good way to provide backward compatibility for older browsers (e.g. providing push/pop for IE5.0). If we can’t do this then we are stuck with only the basic features of the language.

Extending Object.prototype is another matter as then we are left with no object that we can use as a hash.”

#2 – Don’t use ‘Array’ for an Associative Array

Use ‘Object’ or people will come and take your Arrays away from you.

Anything that extends Array via Array.prototype will break for(in) loops. Because we are leaving ‘Object’ alone, we can use it as an Associative Object.

var x = new Object(); // var x = {}; will work too
x["a"] = "A";
x["b"] = "B";
x["c"] = "C";

It works. Try it. Now.

Now, I have seen lots of code in the wild that does use for(in) to iterate an ‘Array’. It does seem to be a natural and forgivable thing for a programmer to do seeing the term is normally taught is “Associative Array”, not “Associative Object”.

Good reference sites give examples that use ‘Array’.

We are choosing to stop this practice.

#3 – There are two types of Library ‘Primary’ or ‘Secondary’

We are still going to have issues if two libraries choose to extend Array and add the same named method (eg. Array.prototype.sortbyname). The more likely pattern is that you are going to use a ‘primary library’ (prototype, dojo, yahoo etc…) with a group of other smaller scripts. (secondary libraries) that just do one thing well.

If you are developing a secondary library, avoid extending the base types. The primary library will enforce its philosophy via its extensions to the base types. A ‘secondary library’ should just do one thing well without having to change the fundamentals.

With the above guidelines we should be able to mix as main secondary libraries together as we want with at most one primary library.

Mixing primary libraries together is going to be hit and miss.

#4 – Port code that uses ‘Array’ for Associative Arrays

Port it to use ‘Object’, Send it back to the author with a link to this blog post.

Try using the new iterators that are built into JS1.5 and above.

The sooner that we fix these libraries, the better.

#5 – Write JavaScript Tools That Warn Of Rule Violations

Anyone writing JavaScript debuggers or JavaScript/HTML editors should add functionality to warn users if they see Arrays being used as Associative Arrays, or Object.prototype being used to extend Object.

Can anyone think of anything else or improve on the above please?