On Libraries and Frameworks

Over the past few weeks, I’ve spent a good deal of time interviewing candidates at HauteLook for a few front end developer positions. While we managed to find a few very talented people, reading through resumes and doing interviews left me shaking my head shaking my head quite a few times. The reason? Libraries and frameworks.

Don’t get me wrong, the influx of so many high quality libraries over the past however many years has been great for developers. Rapid Application Development has become much easier; the headaches we all encounter when dealing with browser compatibility issues have become less migraine-esque; it has become much easier to add effects that could, in the past, only be achieved with Flash.

And this is bad how?

The problem is that too many developers forget that outside of the library they are using, the rest of JavaScript still exists. (Note: This isn’t a problem native to JavaScript alone, although it is more prevalent due to the popularity of the language as a whole.) I’ve interviewed people with over a decade of experience, people who say they are experts in JavaScript development (which, in itself, is another topic for another day) that didn’t know what JSON was. Had never even heard of it. Or developers who say they work with Ajax on a daily basis, yet don’t know what the XHR object is.

How important is that, really, though? How many developers work directly with the underlying XHR object anymore? Doesn’t everybody use some sort of wrapper for it? The whole point of developing those libraries and frameworks in the first place was to make our lives easier.

Because understanding what is going on underneath the hood makes us better developers
It makes us more capable of solving problems when something has to be done that the library doesn’t support; it makes us able to write code that runs faster and is more responsive because we understand where the inherent bottlenecks lie in JavaScript; it allows us to get more out of the library we’re using, simply because we understand various design patterns and behaviors unique to the language.

An example

The following two bits of code do the same (useless) thing: append 5,000 numbered divs to the body tag. The first function could easily be written by someone who has spent five minutes reading the docs for jQuery. And yet the latter function, while (much) more technically complex, runs approximately 20% faster than its predecessor. The reason? The latter function only hits the DOM once, whereas the former hits the DOM 5,000 separate times. DOM interaction is slow, something that developers who truly know the language understand and (should) take into account in their programs.

for(var x = 0; x <5000; x++) {
   $("<div>").text(x).appendTo("body");
}

(function() {
    var divs = $("<div>").attr('id', 'test');
    var test = function() {
        $("<div>").text(x).appendTo(divs);
    }
    for(var x = 0; x < 5000; x++) {
        test(x);
    }
    divs.children().appendTo('body');
})();