Tuesday, May 16th, 2006

Revenge of the $

Category: Editorial, JavaScript, Library

There was a lot of talk on namespaces, and conflicts with the $ function.

This problem is made worse in the JavaScript world due to the fact that you have to ship the JS that your app needs each time. Practicalities mean that a lot of developers have build tools that generate a minified js file. One big file. One download.

This has lead to years of copy ‘n paste reuse. I have seen people take the $ function from Prototype and put it in their own helpers.js file.

If we could declare standard libraries and have them cached in the browser nicely we wouldn’t have this problem:

  • import dojo.foo v2.1
  • import openajax.$ v3.0

We could standardize $ and keep it simple.

Posted by Dion Almaer at 10:06 am

2.5 rating from 56 votes


Comments feed TrackBack URI

I think I’d prefer browsers fixing their JS/DOM glitches and limitations first.

Comment by rick — May 16, 2006

Alex from dojo is hardoff against prototype and very condescending in his tone. He is so biased that I instantly ignore most of his posted against Prototype. The dude needs to let go of the fact that not everyone thinks his way or uses his framework.

Comment by Mario — May 16, 2006

I think he might be understandably annoyed with prototype. What they do with native object types is very naughty from an engineering perspective.

It would be the same if they had built a bridge but decided that on this particular bridge they were going to build special toll booths that only “prototype” friendly cars could drive through.

Thankfully building bridges requires building licenses and for people to follow basic engineering practices…Like making sure their bridge will work with all cars AND their own special car.

That’s the difference between a toolkit developed by designers and a toolkit developed by engineers. (not that prototype doesn’t have a lot of very cool features that show a great knowledge of JS in general…it’s the engineering part that rubs me the wrong way)

Comment by Jesse Kuhnert — May 16, 2006

@Rick – Not sure where you got all the mention of Alex from, he was talking about this at the deveoper day, but this isn’t his posting. Also, just because he’s bias towards his framework doesn’t mean he doesn’t have anything good to say. $ is causing problems as its implemented different ways in different frameworks now, anyone who tries to use more than one framework runs a chance of breaking things which is what the issue really is about.

Comment by Rich Waters — May 16, 2006

Sorry, misread the above my comment is directed at mario.

Comment by Rich Waters — May 16, 2006

It’s worth mentioning that prototype has already changed the definition of $ in the 1.5 tree.
$ now extends the returned DOM element, allowing things such as $('foo').hide();

Although the syntax is pretty, this makes $ slower than document.getElementById() and breaks prototype’s co-existance with many other libraries (in my case it was AjaxPro).

This has been a big headache that has caused me to start typing document.getElementById() again.

Prototype is great, but Alex Russell had this one right all along.

Comment by Bill Lanides — May 16, 2006

Alex Russell’s only real problem is documentation. Who cares about the personality stuff. Heck, we all have those ego quirks! Alex says Dojo has a plan regarding documentation. I hope that plan is realized sooner than later. Delivering well documented (meaning for engineers and designers) toolkit in Jan ’07 will result in lost opportunities. I hope this “plan” comes before August. DOJO seems great, but why isn’t it wildly popular? I think it comes down to designer’s inability to understand DOJO on their own. They can make the leap to prototype because it fits their thinking about javascript and because there’s much more documentation across web to fill in anything designers can’t figure out themselves. Dojo needs to embrace the designers to drive broader adoption, plain and simple. Kind of funny, but I really think that’s how it works.

Comment by Dave Hemminger — May 16, 2006

Guess I just can’t get enough of browsing these comments today :)

In response to the documentation aspect of dojo, there are a number of solutions already in the works. Not suprisingly, a generic parser that is capable of documenting ~any~ JS code is one of these solutions. Vive le engineering :)

Comment by Jesse Kuhnert — May 16, 2006

Erm seem to be having some weird issues with this site, both my posts were showing up when I viewed the page, but not in the rss feed, reloading the page made my original post disappear….

@Mario – Not sure where you got all the mention of Alex from, he was talking about this at the deveoper day, but this isn’t his posting. Also, just because he’s bias towards his framework doesn’t mean he doesn’t have anything good to say. $ is causing problems as its implemented different ways in different frameworks now, anyone who tries to use more than one framework runs a chance of breaking things which is what the issue really is about.

Comment by Rich Waters — May 16, 2006

I am for using $ as an alias to document.getElementById() and nothing more. It is potentially dangerous in that you’re adding a globally-scoped object, but I think it’s a pretty miniscule one-off when compared to the years of existing “everything global” JS out there. It’s a small trade-off that saves a lot of code repetition and in my opinion, helps readability. $(‘someID’), for example, is pretty concise. It could also be scoped to a namespace eg. YAHOO.$(‘someID’), but the brevity of $() is what I think makes it attractive. I’m not interested in making aliases for all DOM methods, but getElementById() is lengthy and commonly-used enough to justify some sort of shortcut.

Comment by Scott Schiller — May 16, 2006

Glad to see this post is rated so low. Though the comments certainly seem to be off topic. Dojo vs Prototype guess we have another vi vs emacs war on our hands.

It hardly seems neccessary to standardize javascript libraries especially if all you are after is Prototypes $() method. The whopping 3 lines of code it takes to write a it’s orginial functionality ( pre 1.5 ) really isn’t enough cause for the commities and meetings and papers and 4 years of faulty browser implementations that’d need to occur to make standardized.

The use of Javascript as a serious programming tool is still in it’s infancy. Standards at that high a level so early in the game would do nothing but wreck the flexibility and future of the language. There is much competition of ideas left to be fought out, and much learning yet to be done. Though I do think Javascript after it’s 2.0 release could stand to see something like the JSR process.

Comment by Vance Dubberly — May 16, 2006

ECMA-262 says:

This standard specifies one departure from the grammar given in the Unicode standard: The dollar sign ($) and the underscore (_) are permitted anywhere in an identifier. The dollar sign is intended for use only in mechanically generated code.

Well, it made me laugh.

Comment by Daniel — May 16, 2006

My views on the Alex come straight from his own comments:

Anyways I Agree Vance.

Comment by Mario — May 16, 2006

why cant we all get along and just stop being lazy and use document.getElementById(”)

Comment by Allen — May 16, 2006

Prototype behaves well if you control 100% of what’s getting onto the page. Where you aren’t, it gets really scary when it comes to mucking about with the native objects.

I still like prototype, but for my recent project, I’ve taken to writing my own library. It’s not as nice as the others, but the one thing it does for me is guarantee me namespace safety (it checks for a usable object name during the load)…

Comment by Ken — May 16, 2006

If you like prototype and PHP check out Prado 3, its a very nice php framework that uses Prototype and has lots of components for it… sorry to be promoting, but I dig the framework (its not mine, i just use it)


Comment by Mario — May 16, 2006

Is this the right time to ask for the Perl-like $_ variable as well? :-)

But seriously, it’s clear that the easy-to-use Prototype functions do come at a cost. For many small or independent projects, it may not matter. Pick your trade-offs.

Comment by Matthias Miller — May 16, 2006

I note that jquery has been doing this the right way for some time now.

Comment by Name (required) — May 16, 2006


As one of the other founders of Dojo, I think it’s worth mentioning that Dojo is much bigger than Alex or what you think of Alex. And I would be the first to agree with you that if you don’t want to use Dojo, then cool, don’t use Dojo, but do use the toolkit or philosophy that works best for you. I look forward to the day when there are more good JavaScript developers than there are toolkits :)


Comment by Dylan Schiemann — May 17, 2006

now that’s a great idea, Dion.

I was recently wondering if I could somehow use javascript bindings into various other langauges (flash, etc) to help speed up my own javascript – for sorting and searching large arrays, for example.

loading a local (pre-compiled, hopefully) version of a full javascript library would be even better, as there would be less translation overhead.

Comment by Kae Verens — May 17, 2006

Dylan, I think that’s great advice; I hope we can all follow it, regardless of our differences in programming philosophy. I have a tremendous amount of respect for the work Dojo is doing, but Alex really does act as if he’s got a chip on his shoulder — as if the mere existence of Prototype makes his life miserable — and the impression that leaves can last a long time. I’m all for a truce, but it’s hard not to notice that one of the guys sitting on the other side of the table clearly thinks I’m an idiot.

Comment by Andrew Dupont — May 17, 2006

I will have to say that based on my experiences this is a serious problem. I do a lot of JSF work and the tendency for JSF component libraries to include prototype and/or to pollute the global namespace is a serious problem to interoperability when you need to use multiple components or libraries. These problems can take a lot of effort to track down and resolve, especially when so many vendors and project designers alike take the attitude of “oh well, you should just use my component/framework/toolkit and nothing else”. In my book that doesn’t cut it. One of the things that I’ve started checking for is mis-use of the global namespace in a component or toolkit before using it.

Comment by Steve McCoole — May 17, 2006

Dojo was the first framework I ever considered. When I began reading the little bit of documentation on the site, I became very excited about the potential. Then I realized that was ALL the documentation. If there was as much documentation for Dojo as there is for prototype, it would have been an easy decision. It’s like so many tools. It all comes down to usability. In the meantime, I’ll stick with Prototype and enjoy the dollar sign. I’ll admit that I do hate that ‘for…in’ for associative arrays has been screwed up.

Comment by Chuck — May 17, 2006

“I’ll admit that I do hate that ‘for…in’ for associative arrays has been screwed up.”

Chuck, I promise I’m not picking on you, but I keep hearing this from people as though this were an actual problem. Prototype does not interfere with associative arrays. I’m guessing you’re trying to use the Array object with string keys, which doesn’t work, and is incorrect. Use a generic Object and you’ll have no trouble with for… in loops.

Don’t get me wrong: I understand the concerns people have about the global namespace, but I swear this associative array “problem” is the only concrete example of something that Prototype has interfered with, and that issue was resolved a year ago (by removing the extensions to Object.prototype). I’m sure other examples exist, but I haven’t personally heard them. Can we get them down on paper or something so that the criticism can be a little more constructive? What does Prototype conflict with, and in what manner?

Comment by Andrew Dupont — May 17, 2006

http://dianesoini.com/2006/04/21/prototype-sux/ for example

Comment by conflict — May 17, 2006

Thanks for the Prototype tip, Andrew. That now seems so obvious that I’m embarrased. It does reinforce my comfort with Prototype.

Comment by Chuck — May 17, 2006


I think Alex has grown up a lot over the past year. I think if/when you meet him, you’ll realize he’s passionate about his work, and sometimes outspoken about it. That said, most dhtml hackers tend to be miserable :), and we’ve all said stuff in our lives that we would prefer to take back

I do know that when prototype was first released, several of the Dojos were upset, not because of what prototype was, but for two reasons: 1) yet another toolkit (Dojo was started through bringing together 4 existing toolkits, and a number of old school dhtml hackers), and 2) we were way too slow getting an initial release of Dojo out the door, losing the chance to provide something you all could build on top of (probably because so many strong personalities were coming together at once and trying to agree on something :) ). For me, I feel bad when good people suffer through some of the mistakes I’ve suffered through already.

I think the adoption of prototype and its derivatives has been amazing, as has the adoption of Dojo and the other leading toolkits. I’m still in awe of the interest in what we are all trying to do here. I think healthy co-opetition (for lack of a better term), along the model of what Opera/Safari/Mozilla, is great for raising the quality of all of our toolkits.

We all suffer through documentation woes, because people want to work on features and bug fixes, not docs. And of course, we all have the problem of docs quickly becoming outdated when code changes as rapdily as it does with the current pace of toolkit development. We’ve been working on a
documentation tool
that we hope many toolkits can use as a starting point for docs.

If you are interested, we would be more than willing to work with you all to increase interoperability, define common APIs, collaborate on development tools, etc. … anything that might make life easier for the bigger development community, and stuff that might encourage people to use existing toolkits rather than starting from scratch. And of course we’d want to do that in a way that had a high signal to noise ratio.

Comment by Dylan Schiemann — May 17, 2006

Dylan, I’ve heard rumors about that documentation tool… it sounds awesome. I can’t wait until it’s ready.

I think it’s a good thing that there are major design differences between Dojo and Prototype — it means that the two are not really in direct competition. Choosing between them isn’t necessarily about which is ‘better’; it’s about which one fits your brain better, and that will vary from person to person. As a result, the competiton between the frameworks is healthy rather than combative (in my opinion). (I think Alex even said something to this effect at the Ajax conference, in contrast with the gruff exterior he sometimes casts on the web. :)

Though I hack Prototype in my spare time, I have no formal affiliation with the project, but I’m active in its informal support mechanisms, and I think it’s a great idea to collaborate on the big-picture stuff. Why don’t you shoot me an e-mail (just follow the link to my site) and we can discuss it further?

Comment by Andrew Dupont — May 17, 2006


whoa whoa whoa, sorry but this comment is wrong

I’m guessing you’re trying to use the Array object with string keys, which doesn’t work, and is incorrect.

Associative arrays are a feature, just because the way they where origionally implemented behind the scenes is unusual, does not make it ” incorrect ” to use. The dollar sign stuff is a hack, the object workaround for associative arrays is a hack, so there is no room to even begin saying that using associative arrays in the classical sense in js is wrong.

Comment by Allen — May 17, 2006


I can’t believe people can’t see that its a mis’use of the Array. When you do var foo = new Array(); foo[‘apple’] = 3, you havent added anything to the array. You have just assigned the foo array object a property named ‘apple’ and = to 3. In other words alert(foo.apple); //returns 3.

Come on now.
var foo = new Object(); foo[‘apple’] = 3; //woah I have an associative object *snicker*

Comment by Mario — May 17, 2006

Allen, can you cite a reference for this “behind-the-scenes” implementation? Or have you just assumed that the implementaton was “behind-the-scenes” because it it works even though it’s not actually endorsed by any JavaScript authority?

It is true that in a pristine browser enviroment, the code below will behave exactly as you would expect:

var arr = new Array();
arr["one"] = 'one';
arr["two"] = 'two';
arr["three"] = 'three';
for (i in arr { alert(i); } // (or your logging method of choice)

What’s also true is that the above code works even when you replace Array with RegExp, Date, String, or Boolean. I know because I experimented just now.

All these objects “work” as hash tables because they’re all children of Object. That doesn’t mean that using them this way is correct, and it certainly doesn’t mean that the prototypes of these objects are hands-off. Most importantly, though, there’s no advantage whatsoever in using Array over Object, so I don’t understand why using Object is the “hack” and using Array is the “feature.”

Comment by Andrew Dupont — May 17, 2006


Yes, I know the point your trying to drive home, in short “Everything is an object so its not really a hack because its the same as array”, this is what I meant by “behind the scenes”…. behind the scenes an array is just an object that your free to have your way with and (insert your previous post here…). Yes I know this, but when it boils down to it, we do have an “array type” and we can insert custom keys, making it the very definition of the technical term “associative array”. Javascript, like every language out there, has a thousand differen ways to mimmick associative arrays. Regardless, considering the very definition of associative arrays, and the fact that we do have an “array type” makes it a feature. As far as I’m concerned, the javascript “authority” is the existing code base that people (in a real development position, not just hobby) use. You cant go messing with the prototype because your too lazy to type document.getElementById(”), and then yell at the authors of the scripts that you just broke saying “your doing this wrong…”. We’ve had people do this, adding $, or adding additional functionality, and consequently breaking 5+ years worth of code. Its caught in testing, and they are forced to code the right way. With that said, for small independantly developed stuff that isnt going to be reused, or as a free standing little project, by all means, use $

Comment by Allen — May 17, 2006

Allen: I suspect the only reason you seem to be equating numeric arrays and associative arrays is because they are more or less the same in PHP. In nearly every other language that comes to mind, there is a distinct separation between them. Ruby has arrays and hashes; Python has lists and dictionaries; Java has arrays and hashmaps. This isn’t just an accident: most languages treat them as different because they are different. (A numeric array, for example, has an explicit order of iteration, whereas an associative array usually doesn’t.)

You seem to be arguing from the position that the two are obviously one and the same, and that the burden is on me to convince you that they ought to be separate. Again, I ask: what advantage is there to using Array instead of Object, other than your argument from linguistics?

Out of curiosity, if modifying Array.prototype (or any other object’s prototype) is such a horrid idea in the first place, then why is it explicitly allowed by the language? (Also: the $ function has nothing to do with any object’s prototype; it’s just an ordinary function. Should defining functions be considered “bad practice”?)

Comment by Andrew Dupont — May 17, 2006

I’m speaking from a purely generic sense of the term “associative arrays”, not php. I’m not going to argue semantics and implementations, we could do that for weeks. Bottom line, people are doing stuff that screws with the initial functionality of the language, and then getting pissy when other people complain that their code (for…in loops) is broken. It wont fly in a real world enviroment, i’ve seen people try, the code never sees prod.

Comment by Allen — May 17, 2006

Allen, my final word on this will be the ECMAScript specification itself. If there is a more reliable source than this on what the “initial functionality of the language” is, then I’m sure you’ll explain it to me. If the spec is at odds with your “production code,” then your code was never “production” to begin with.

Comment by Andrew Dupont — May 17, 2006

I know PHP allows you to set keys n such. $foo = array(‘bar’=>3); n jazz. I don’t know if count($foo) would return 1 or not… prolly would… unlike js where foo = new Array(); foo[‘bar’]=3; alert(foo.length) does not return 1.

It flys in my real world environments just fine. Then again, everything is built in from prototype 8P.

Comment by Mario — May 17, 2006

var koolaid = new Object();
koolaid[‘Flavor’] = ‘Bogus Blind Sheep’;


Comment by Mario — May 17, 2006

@Mario : Pot, Kettle, Black, Boom! You’ve completely unconvinced me as anyone who’s opinion merits any weight. You portray yourself as much a ‘troll’ as those you’ve accused of such.

Comment by flamebait — May 17, 2006

Andrew, I can see your point that using Array as a hash instead of Object is incorrect and misleading, but you seem to be willfully ignoring Allen’s point which is that Prototype has the potential to break other scripts. Just because those other scripts don’t follow your semantic standard doesn’t mean they aren’t depending on standard behaviour. I mean, an array is an object right?

More importantly, debugging javascript interdependencies of this type is a nightmare. Semantic nitpicking about how certain code is wrong is little consolation for the developer who’s code works without Prototype, but breaks when Prototype is included.

Comment by Gabe da Silveira — May 17, 2006

Ya I am a Prototype Fanboy. You got me 8P. Opinions are like… well you know the rest.

Over’n Out on this post.

Comment by Mario — May 17, 2006

Good Point @Gabe da Silveira. I could see where that would be annoying.

Comment by Mario — May 17, 2006

I’m sorry I suppose javascript code at LexisNexis which has over 200 thousand dollars in revenue pass through it each month isnt “production” enough for you. I’m not looking through that pdf but a quick search for associative yields nothing along the lines of associative arrays, either way its been used and is common knowledge that some people do in fact use it. In a large group, declaring an array and seeing custom keys be used on it, its easy for other team members to say “oh.. thats an associative array” and be about their merry little business. Other than that Gabe da Silveira makes my point fairly concisely.

Comment by Allen — May 18, 2006

Very entertaining discussion, thanks!

Comment by Marty — May 18, 2006

Gabe: this is true. Prototype breaks any scripts that rely upon Array to work with string keys. This is not Prototype’s to fix, however.

To use an example: a few comments ago, someone linked to a blog post that noted its author’s inability to get Prototype and TinyMCE to work on the same page. Investigation reveals that this conflict is caused by TinyMCE’s improper use of Array with string keys. (TinyMCE is otherwise excellent, so it goes to show how common this mistake is if such a robust tool employs it.) I’ve filed a bug on TinyMCE’s SourceForge project, and since the fix is so simple I hope it’ll get done soon.

If there are those who still think that using string keys in Arrays is a valid practice and should not be discouraged, they ought to read my recent article on this topic: JavaScript “Associative Arrays” Considered Harmful. It makes an exhaustive argument, one far too long to fit in this comment.

Comment by Andrew Dupont — May 18, 2006

Wow! What I can of worms I opened! It seems ironic that the HelloWorld Dojo tutorial came out on the day after I whined about the lack of Dojo documentation and spurred the “Associative Array debate of 2006”. Not that the tutorial answers all my questions, but it is nice to see efforts in that direction.

Comment by Chuck — May 18, 2006

Thanks for the great info, will tell all friends and family. Also please visit my blog and leave a comment http://www.heatingairconditionrepair.com, thanks.

Comment by airconditioningservice — October 6, 2011

Leave a comment

You must be logged in to post a comment.