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
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.
- 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.
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.
Here are just some example calls of each of the functions in dLite:
- var container = elm(“container”);
- var externalLinks = elmsByClass(“external”, a);
- addClass(elm(“container”), “active”);
- removeClass(elm(“container”), “active”);
- addEvent(elm(“container”), “click”, handleClick);
- removeEvent(elm(“container”), “click”, handleClick);
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.
Suffice to say, dLite is for me. Is it for you? 🙂