JavaScript Frameworks Suck

There's been an interesting discussion off and on around the office this past couple of weeks about JavaScript frameworks, specifically which framework is the best so we can standardize on one. Of course I have to be difficult... my answer is none of them.

As a general rule of thumb, "frameworks are evil." There are exceptions, but frameworks seem to cause a lot of unnecessary bloat, make tasks difficult to accomplish if they fall outside the intended scope of the framework, create obstacles to efficient debugging, and adversely affect page load times causing the application to appear slow and sluggish. The real question ought not be what framework is best, but rather be what exactly are you trying to accomplish with client-side scripting in the first place.

Creating a rich user experience with standard JavaScript is not difficult. Many of the niceties the frameworks provide aren't magic... for example, $() is just function(x) document.getElementById(x);}. And AJAX is easy if you forgo XML in favor of JSON as your transfer format. If you don't understand your goals then you might as well just shoot yourself in the foot.

Once you have identified exactly what your needs are, and if those needs suggest you use a framework, then those needs will also dictate which framework would be suitable for use. If you need widgets, for example, then YUI! would stand out more as the best choice. If you need modularity and flexibility instead, then MooTools might be the way to go.

To further illustrate my point to a coworker that frameworks don't always make things easier, I implemented a basic Accordion widget in MooTools and straight-up plain old JavaScript. The development time in JavaScript proper was half-that of developing with MooTools because I didn't have to learn any special APIs, scrounge the documentation for a list of dependency files, etc. My implementation weighs in at 50 lines vs. MooTools' 3,100+ lines and 21 dependency files.

function $$(className) {
    var classElements = new Array();
    var els = document.getElementsByTagName("*");
    var pattern = new RegExp('(^|\\s)' + className + '(\\s|$)');

    for (var i = 0, j = 0; i < els.length; i++) {
        if (pattern.test(els[i].className)) {
            classElements[j] = els[i];
            j++;
        }
    }

    return classElements;
}

function Accordion(headerClass, panelClass, showIndex) {
    this.headers = $$(headerClass);
    this.panels  = $$(panelClass);

    for (var i = 0; i < this.headers.length; i++) {
        this.headers[i].args = {
            index: i,
            headers: this.headers,
            panels : this.panels
        };
        this.headers[i].onclick = function () {
            var a = this.args;
            for (var i = 0; i < a.panels.length; i++) {
                a.panels[i].style.display = ( i == a.index) ?
                    "" : "none";
            }
        };
    }

    (showIndex === undefined ? this.headers[0] : 
        this.headers[showIndex]).onclick();

    return true;
}

window.onload = function() {
    new Accordion("a_header", "a_body");
};

Sure it's not as "feature rich" as MooTools' Accordion, but any additional features can easily be added when the time comes, and they certainly wouldn't require 3,050 more lines of code.

People want fast front-ends. They're impatient and don't want to wait. Bloated code slows down the front-end and gives them impression of a slow back-end. Half the development time and 98.4% less code? Now that sounds good to me!