[JavaScript] Naming Your Function ‘$’ is not Clever

The atrocity that is the dollar function dates back at least 2005 and the introduction of the Prototype Framework. Back in those days, ‘$()‘ was simply a shorthand way of saying ‘document.getElementById()‘ without having to type all 24 characters. And don’t get me wrong, aliasing ‘document.getElementById’ to something shorter is not a bad idea, in and of itself. But why should ‘$()‘ be the alias? Such a name gives no clue that the function is looking up a DOM element by its id. Something like ‘findById()‘ (or even ‘$findById()‘ if there are concerns about naming collissions) would have been infinitely more clear, and still a good deal shorter than writing ‘document.getElementById()‘.

But sadly, Prototype decided to use ‘$()‘ as the name of their alias. And even worse, other frameworks have followed in this pattern, adding their own dollar functions that have semantics that can be completely different from the original ‘$()‘ introduced by Prototype. Consider jQuery, which introduces its own version of ‘$()‘ which can be used to find (and wrap and clone) elements in the DOM by a number of different criteria, but which sadly fails miserably when given a string containing a literal element id. This creates a lovely situation where now the developer cannot even guess at what ‘$()‘ is actually doing without first checking to see which framework is being used by the code. It also means that any code that was written using Prototype’s ‘$()‘ will be broken by including jQuery (and vice-versa).

“But that’s what ‘jQuery.noConflict()‘ is for”, you say. But you miss the point. It shouldn’t be necessary for ‘jQuery.noConflict()‘ to exist in the first place. If the jQuery developers hadn’t decided that it would be cute to define their own version of ‘$()‘, then jQuery would never conflict with anything except possibly an older version of jQuery. The thing that really baffles me is how so many developers (obviously talented developers, at that, considering the work that goes into something like Prototype or jQuery) can all decide that it is a good idea to try to lay claim to a name that exists in the global scope. Granted JavaScript does not have any concept of a proper namespace, but if jQuery limited itself to only setting properties on an object named “jQuery” and Prototype did the same on an object named “Prototype” and so on, the current JavaScript landscape would look ever so much more sane.

And of course, this says nothing of the ‘$$()‘ and ‘$F()‘ functions that were also introduced by Prototype (and the ‘$E()’ and ‘$ES()’ functions inexplicibly introduced by MooTools) and whose names are so semantically worthless that a developer has no hope of inferring their function without consulting the reference documentation. Which again can only be accomplished after checking the entire codebase to determine which framework it is that is defining these functions with its woefully awful naming convention.

If the developers of Prototype, jQuery, Mootools, and the like wanted to turn JavaScript into an unreadable and unmaintainable mess of a language like Perl, then I applaud them for their efforts. But if not then I call them all out on their atrocious naming convention and design decisions. There is no excuse for this nonsense. If you’re building a JavaScript library or framework, then pick a reasonable “namespace” to use for it. This namespace should be the only thing that you bind in the global scope. Everything else that is part of your library should be bound as a property inside of this namespace. And there should be no automatic creation of shorthand aliases in the global scope.

I don’t think this is too much to ask. And of course, any developer that wants to use a global shorthand alias can always do:

window.$J = jQuery;
window.$P = Prototype.$;  //or:  window.$P = document.getElementById;

It takes all of one line of code to set up an alias. But when you start doing this automatically for everyone that uses your framework you create nothing but problems. Especially when you jump on the bandwagon and choose the same crappy shorthand alias names that other frameworks are already using.

There is absolutely no reason why multiple JavaScript frameworks should all be competing over the same terrible function names. This isn’t a contest to see who can break the most legacy code, or who can come up with the most obtuse API. They do have such contests if you are interested in such a thing, but this is not one of them. The only thing accomplished by parading the dollar sign around as an example of a well-chosen function name is an increased brittleness in the code that glues together the majority of our modern websites. It muddies semantics, and creates cases where completely unrelated libraries are not easily compatible with each other, and where simply importing a new library can cause existing code to break. Even worse, some novice developers get the wrong idea from all those dollar signs flying around think that they need to (or should) prefix all of their function names with “$”. So let’s put this bad practice to bed before it’s too late.

So please, can well all stop writing frameworks that give people the impression that calling a function “$”, “$$”, “$ES”, or “$anything” is a good idea? Is it so difficult to choose a reasonable namespace, minimize the number of things that you declare in the global scope, and allow the developer to define a global shorthand alias for this-or-that utility function if they decide they want to? I think not.

This entry was posted in coding, javascript and tagged , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>