I've just been having a heated discussion with a client where the term "javascript zoo" was born.
The argument constructive discussion arose over an issue with a plugin they are developing (based on our rate plugin).
A JavaScript zoo
I suggested using the awesome jQuery plugin instead of dealing with issues regarding the prototype plugin (see later).
The client said this would be a "zoo of javascripts" with multiple versions of multiple libraries.
In some respects it would, which is why I think all the other animals should be killed and fed to jQuery.
Note: The client also has Dojo, Dijit and a herd of custom JS scripts in their widgets so adding jQuery would be barely noticable heh.
The real "zoo" is prototype (and any other non-namespaced, bloaty library)...
Prototype is the Zoo!
The client wanted to use Prototype 1.5.1.1. Unfortunately Confluence for some reason is using version 1.4.0_pre11 - that's like an ancient preview release of 1.4. (Why oh why don't Atlassian upgrade this? Rargh!)
As I mentioned in my recent blog post about JavaScript Frameworks, prototype is a very messy library.
First, it inflicts it's horror on every single javascript object. This means that whether I want to use prototype or not, every JS object is now infested with methods and properties that aren't part of the ECMA 262 specification. I'm no longer working with JavaScript, I'm working with a prototype-infested scriptmare.
In something like Confluence there are lots of different developers, plugin authors, etc., who all need to send their stuff to the browser. They are all forced to live with the mess that prototype creates. The temptation to start using prototype, therefore, is high - it's caused you pain by messing up your iterators and other stuff, you might as well try and take advantage of some of the mess it offers. Now you start getting all sorts of functionality - both native to Confluence and third party plugins, etc., being assimilated by the prototype virus of doom.
Also, because prototype isn't namespaced you run in to some painful problems when you try and include two versions of it at the same time. You end up overwriting some, but not all, of the old methods, objects, etc. Anything that accommodated bugs in the old version will now break as the new version won't have those bugs (or have new bugs). There's no way for me to say: actually, my code needs the latest version but I want the old version as well for compatibility with other peoples' code.
To make matters worse, we found that prototype 1.4.x is included twice in Confluence - once in labels-javascript and once as a dependency of script.aculo.us. Now the clients' adding in a third copy (albeit 1.5.1.1) so to view a single page you now have to load painful prototype death 3 times! And it all gets mingled together causing untold problems.
Adaptavist don't use it
The client was very surprised to see that Adaptavist's rate plugin doesn't use the "excellent prototype library which is a very good solution". Heh.
Yeah, and with good reason.
First off, we avoid being overly reliant on what Confluence delivers to the browser. We never know when Atlassian will make changes to their HTML, JS or CSS so generally we avoid it like the plague. This is why Theme Builder and our other plugins generally survive Confluence upgrades.
Second, we don't want to spread the prototype virus of doom. If our plugins used it, then we'd just be another reason never to remove it.
Adding jQuery to the zoo!
By default, jQuery is not enabled in Theme Builder 3 - we don't want people downloading yet another JS library unless it's actually getting used. A simple switch in the layout manager turns it on (and related switches allow you to also include some hand-picked jQuery plugins) - all on a layout by layout basis so it doesn't have to be used throughout the entire site, you could just apply it to a single page if desired.
Anyway, the client found it odd that we would prefer to use jQuery over prototype, considering several versions of prototype are already being loaded 
We'd prefer to use jQuery because it's namespaced. It doesn't inflict itself on everything else. If we ever had a scenario where we needed multiple versions of jQuery, it would be really easy to do.
Also, jQuery doesn't try to do too much. A lot of people don't appreciate how important this is.
jQuery is aimed at being picked up and used whenever it makes sense to do so, but then doesn't get in the way when you don't want to use it. It's not sitting around on all the JS objects just in case it's needed. It's tucked away inside a very well behaved namespace.
Anyway, just needed to vent my spleen. Back to coding...
Added by