Looking at how JavaScript has and its usage has evolved, and also taking in how most JavaScript libraries seem to try to cater for every possible need people might have, I thought it was about time to get back to the basics. To me, that is spelled dLite.

There are large projects where using a JavaScript library packed with features is definitely a good thing, both for the web developers and business-wise. However, I’d like to argue that most JavaScript libraries in the state they are today are complete overkill for what people actually need.

A lot of developers want one or two functions, and for that, they have to pay the price of including a monolith of over 100 kb, with which they then have to work hard with to minimize, gzip it etc. Another downside with JavaScript libraries is that they have, more or less, completely replaced the native DOM referencing syntax in JavaScript, forcing each developer to read up on the particular library used in their current project.

I definitely think that, with an agile mindset, just looking at the code and directly understanding what it does, shouldn’t be underestimated.

Analysing peoples’ actual needs

A while back John Resig wrote Selectors that People Actually Use, based on some of his research, and overall it goes to prove what I also believe. A majority of web developers don’t need a lot of CSS selectors, using inheritance for JavaScript object creation, complete DOM traversing etc. They want something easy and light-weight.

I’ve worked with developing web sites for a long time, and has over the years spoken to numerous web developers who has asked for simplicity and just features they actually need. And, their needs have been exactly the same as mine: element referencing, class name filtering, event handling and a couple more things.

Therefore, my strong belief is that what most people need to do when developing JavaScript is:

• Get a reference to an HTML element.
• Find out when the DOM has loaded and start working with the document.
• Find elements with a certain class name.
• Add and remove events on elements.
• Add and remove CSS classes on elements.
• Stop default behavior and cancel bubbling for events.

Those things, and probably in that order too, is what such a large portion of web developers do when they’re working with a document.

Creating dLite

With my conviction that people need less, not more, I set out to create a very small set of JavaScript functions to take care of the above needs, and to make referencing them as easy as possible. The result is dLite (download dLite).

The functions in dLite are:

• elm – find element with a certain id
• elmsByClass – find elements with a certain class name
• DOMReady – run functions as soon as the DOM is loaded
• addClass – add a class name
• removeClass – remove a class name
• addEvent – add an event handler
• removeEvent – remove an event handler
• stopDefault – prevents the default behavior of an event
• cancelBubbling – cancels the bubbling of an event

Simple referencing and name assertions

All dLite functions are available in the global scope, meaning you don’t need to call them with any objectName.methodName notation, since namespacing in, like, five steps is usually just annoying and tedious for people. If, for any chance, that function name already exists in your document, it will not be over-written by dLite.

The functions in dLite are also offered as methods through a dot notation on the dLite object, both as a last resort when the name is already taken in the global scope, and to cater for the web developers who do prefer using a dot notation in their code.

The name of the functions

The idea is that each function has a semantic and self-explanatory name, so any developer looking at the code will understand what it will do. The names are deliberately close to the native DOM methods, to make it easier to adapt to, but at the same time guaranteed to avoid name collision.

Example code

Here are just some example calls of each of the functions in dLite:

elm

var container = elm(“container”);

elmsByClass

var externalLinks = elmsByClass(“external”, a);

DOMReady

DOMReady(runAtDOMLoad);

addClass

addClass(elm(“container”), “active”);

removeClass

removeClass(elm(“container”), “active”);

addEvent

addEvent(elm(“container”), “click”, handleClick);

removeEvent

removeEvent(elm(“container”), “click”, handleClick);

stopDefault

stopDefault(evt);

cancelBubbling

cancelBubbling(evt);

The name

The name dLite is partly meant that it will be a delight using it to develop, partly because some of the functionality is derived from DOMAssistant, so that it, in some sense, is a DOMAssistant light.

dLite’s target audience

A while back James Edwards, aka brothercake, wrote You’re Fat and I Hate You where he discusses what he himself thinks is “real developing” and about the need to being able to read the source code, and tweak it to any possible need.

I think one of his good points is that a lot of developers write code that do amazing things on the screen, but they have no idea how it works. With dLite, it’s the other way around: it is for you anyone who wants to know how, and why, things work, and personally I believe that that is the only way to truly be able to write the most optimized and maintainable code.

Therefore, dLite is for JavaScript developers who just want a couple of helper functions to sort out the most common tasks and web browser differences, and then dive in themselves, head-first, into the code and build their own JavaScript worlds.

Suffice to say, dLite is for me. Is it for you? 🙂