Skip to main content

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!

Comments

  1. The availability of already-built components in frameworks can be as much of a boon as a hindrance, I think.

    One advantage they do provide is logic to handle cross-browser compatibility issues, rather than requiring you to do research and pull your hair out trying to figure out why something works in one browser and not another.

    Assuming caching is properly used, bloat past the first request should be a non-issue. I will admit that JS frameworks could stand to be more flexible, though that sometimes comes with additional verbosity.

    Unfortunately, due to the environment in which JS is generally used (i.e. the client side of web applications), we don't have the same include-on-demand advantage that languages like PHP provide us, at least not to the extent that it doesn't pose a problem with caching.

    I will admit that sometimes rolling your own solution makes more sense, though I don't think that's always the case.

    ReplyDelete

Post a Comment

Popular posts from this blog

Geolocation Search

Services that allow users to identify nearby points of interest continue to grow in popularity. I'm sure we're all familiar with social websites that let you search for the profiles of people near a postal code, or mobile applications that use geolocation to identify Thai restaurants within walking distance. It's surprisingly simple to implement such functionality, and in this post I will discuss how to do so.

The first step is to obtain the latitude and longitude coordinates of any locations you want to make searchable. In the restaurant scenario, you'd want the latitude and longitude of each eatery. In the social website scenario, you'd want to obtain a list of postal codes with their centroid latitude and longitude.

In general, postal code-based geolocation is a bad idea; their boundaries rarely form simple polygons, the area they cover vary in size, and are subject to change based on the whims of the postal service. But many times we find ourselves stuck on a c…

Creepy JavaScript Tracking

I recently began allergy shots so my new Monday morning routine includes me sitting in a doctor's office for 30 minutes (I must wait after receiving the shots and be checked by a nurse to make sure there was no reaction). With nothing else better to do while I waited last week, I started playing around with some JavaScript. This is what I came up with:
<html> <head> <title>Test</title> <script type="text/javascript"> window.onload = function () { var mX = 0,  mY = 0, sX = 0,  sY = 0, queue = [], interval = 200, recIntv = null, playIntv = null, b = document.body, de = document.documentElement, cursor = document.getElementById("cursor"), record = document.getElementById("record"), play = document.getElementById("play"); window.onmousemove = function (e) { e = e || window.event; if (e.pageX || e.pageY) { …

Composing Music with PHP

I’m not an expert on probability theory, artificial intelligence, and machine learning. And even my Music 201 class from years ago has been long forgotten. But if you’ll indulge me for the next 10 minutes, I think you’ll find that even just a little knowledge can yield impressive results if creatively woven together. I’d like to share with you how to teach PHP to compose music. Here’s an example: You’re looking at a melody generated by PHP. It’s not the most memorable, but it’s not unpleasant either. And surprisingly, the code to generate such sequences is rather brief. So what’s going on? The script calculates a probability map of melodic intervals and applies a Markov process to generate a new sequence. In friendlier terms, musical data is analyzed by a script to learn which intervals make up pleasing melodies. It then creates a new composition by selecting pitches based on the possibilities it’s observed. . Standing on ShouldersComposition doesn’t happen in a vacuum. Bach was f…