The other day someone asked me again about what I thought about jQuery, and I’m getting tired of repeating myself for almost a year. jQuery actually is fodder for an interview question I sometimes ask:
What’s wrong with the jQuery $() function?
[Showing you the money after the jump.]
What is $?
If I take the example from this article:
$('#external_links a').click(function() {
return confirm('You are going to visit: ' + this.href);
});
Here, $() is equivalent to the $$() function in prototype. And $(‘#…’) is the same as $() in prototype which is a “safe” way to do document.getElementById() + some stuff to object prototype inheritance to correctly work in Internet Exploder.
It is a very attractive shortcut if you don’t stop and think about its consequences. In the example given, the above code is a shortcut for the following more verbose code:
var external_links = document.getElementById('external_links');
var links = external_links.getElementsByTagName('a');
for (var i=0;i < links.length;i++) {
var link = links.item(i);
link.onclick = function() {
return confirm('You are going to visit: ' + this.href);
};
}
Looks pretty cool huh? Looks are deceiving. The more verbose code executes faster, plus, it isn’t all that realistic… your external links wouldn’t be located in some place but would instead be referenced by class name. Even faster code would look like.
for (var i in document.links) { // technically a for-do is marginally faster
var link = document.links[i];
if (link.class !== 'external') { continue; }
// better and more DOM scripted to replace the below with a YAHOO.lang.augmentObject
link.onclick = function() { return confirm('You are going to visit: ' + link.href); }
}
It’s all about the Benjamins
The first time my ex-girlfriend saw me code PHP, she asked me:
“What’s with all the money in PHP?”
It took a while to understand she was referring to the dollar signs in the language. And geek that I am, I actually explained to her what variables are.
But that’s the problem with jQuery in a nutshell. It makes a function look a lot like a variable. How is that a problem? Let’s look at this:
$('#blah').href = 'http://www.example.com/';
$('#blah').style.display= 'none';
$('#blah').style.visibility = 'hidden';
Oh, don’t tell me you’ve never seen someone do this! Programmers are lazy and I call bullshit on that. When you make something look like a variable, a programmer is going to start treating it like one.
I like to say:
The reason
document.getElementById()is hard to type is because it’s slow to execute.
Oh, I’m sorry, it’s even slower to execute because this isn’t even doing a getElementById(), it’s doing a xpath search selector (getElementsBySelector()) which is even slower! And where is the optimizations for taking advantage of the built-in and infinitely faster document.images or document.links?
It gets worse from there because of DOM scripting. Not that there is anything prima facia wrong with DOM scripting, it’s just that programmers have a tendency to DOM script without considering the very real performance consequences. I spent a few days undoing the DOM scripting of hyperlinks that a developer hacked in via YAHOO.util.Dom.getElementsByClassName(). Hyperlinks!!! My God, man. They’re links, they’re supposed to be “linked.”
Show me the money
When I heard about this style syntax in prototype I was attracted to it for all of ten seconds. Abstraction costs and that should be intuitively obvious to the casual observer. In jQuery programmers are abstracted from the very real costs of their actions. This leads to sloppy and slow UI code. Almost all jQuery code I’ve seen executes slow for what it does.
jQuery is basically modelled after prototype. Is it any surprise that prototype is both heavily adopted and influenced by Ruby on Rails developers? What is it about Ruby acolytes that they wish to abstract themselves from the very parts of their systems that they know will be their bottlenecks?
Beyond that, is what I really want in a framework library—be it prototype or jQuery: a bunch of useless macros with some backward compatibility window dressing? History has shown that the most successful frameworks are ones that abstract and standardize the graphic user interface, not ones which give me a forced structures for events, ajax, iteration and the like. I am usually willing to pay for that “crap framework” cost only if it gives me real return in the form of higher order user interface widgets where the real programmatic cost-savings occur. User interface always ends up being at least half your code base, and it’s definitely the half programmers like to code the least and it’s often the half with the most bugs in it—users just don’t seem to behave like we want them to.
Stop preaching me your “framework religion” in the form of base structures and bullshit shortcuts and start giving me results in the form of fast, light, powerful user interfaces.
Until then, you’ll just be interview question fodder: another Javascript Framework developer bites the dust.
