JavaScript Abstractions

jQuery, MooTools, Prototype, YUI and Dojo all have at least one thing in common; they’re all partial abstractions of JavaScript, the “official” client-side programming language. Each of these frameworks enables further abstraction whether it is through “plugins”, “extensions” or “classes”. So where does the abstraction end? Or rather, where should it end?

The point in abstraction is to make something simpler by factoring out details. If we take jQuery for example, it abstracts away cross-browser pains; it essentially covers up the difficulties. This can make for faster development but can sometimes result in an abstraction leak.

The law of Leaky Abstractions, a term coined by Joel Spolsky, states that “All non-trivial abstractions, to some degree, are leaky”. A “leak” occurs when an abstraction breaks and you have to resort to a lower level abstraction to solve the problem. So, if jQuery fails to provide cross-browser sanity in a particular situation then you’re left to battle it via “pure” JavaScript (a lower level abstraction).

This highlights a common controversy: is it necessary to know JavaScript at all? Are you comfortable operating on a wafer-thin high-level abstraction like jQuery, MooTools, Prototype or any other framework? What’s your course of action when your beloved abstraction leaks?

How low can you go?

So, given that all abstractions are, to some extent, leaky, how low should you go? I think this can be answered with another question, how low can you go given the constraints of the platform? With our jQuery example the platform is the browser; this piece of software does not offer anything lower than JavaScript, so surely that’s as far as you should go!

Similarly, with CSS frameworks like BlueprintCSS and 960gs you should go as low as you can, which, in this situation is CSS itself.

Using frameworks is absolutely fine as long as you know the technology on which the abstraction was formed. If you want to use jQuery, learn JavaScript; if you want to use a CSS framework then learn CSS!

This get’s more complicated in the area of software engineering because the platform allows you to go very low. Should all .NET developers know how to write C++, should all C++ programmers have a strong grasp on Assembly? I can go on forever…

It’s a compromise!

If we define “control” as a reasonable level of supervision over a piece of functionality (whether it’s a form validator or an image cropper) then it has a negative correlation with abstraction; in other words, the higher the level of abstraction, the less control you have.

Recently I discussed the benefits of creating a jQuery plugin but I failed to point out the obvious flaw: by creating a plugin or extension for any framework you’re raising the level of abstraction even further covering up the details), thereby decreasing the level of control someone has over it. Fortunately, because it’s JavaScript, we never really lose control; we can change the plugin source at any time. But the end user of your plugin probably won’t know JavaScript to the same extent as you. The level of control they have is dictated by the level of customisation you offer with the plugin; but, the more customisation you offer, the bigger in size the plugin will be. Therefore the entire process is a compromise between control, simplicity, and most importantly, speed!

The higher the level of abstraction the slower it will be. Higher abstractions may speed up development time but the processing time will usually be longer.

document.getElementById(‘elem’) will always be faster than $(‘#elem’)!

Food for thought…