Or: There are legit reasons to write your own library
Around the office it’s no secret that I’m a fan of the MooTools JavaScript library. For those of you who can remember back before jQuery, Moo.fx (from whence MooTools came) was a tiny, feature rich library for animations and effects. It was a welcome relief from having to write effects and deal with the cross-browser issues that invariably crop up. Compared to the heavy weight (and necessity) of including both the Scriptaculous and Prototype libraries, Moo.fx was a boon for byte-pinching developers and infrastructure managers.
Over the years as many libraries popped up and fell by the wayside, jQuery came along and showed us the difference between a library and a framework. Perhaps the most important result of competition between libraries was performance. I won’t hold MooTools above any other library arbitrarily but when they created SlickSpeed it was a great way to show performance between libraries and let developers decide what library best fit needs. John Resig came along and blasted out Sizzle and – BAM – kicked up the speed of jQuery by a wide margin. The healthy competition rages on and it just means better speed, compatibility and features for users of JavaScript libraries.
With the availability of tested, proven, mature libraries why would anybody ever bother writing their own native JavaScript code any more? I know that the last time I write document.getElementById() can’t come soon enough. Still, there are reasons to stick to pure, native JavaScript.
For starters, no matter how elegant or optimal the code a library’s code will never be as efficient as native JavaScript. Sure, they may delegate to native functions and the cost could end up being a millisecond or two. That’s fine. Then again, do you want to be the one tracing back performance issues when your code causes a locked browser when you run var header = $('header'); and hit some kind of weird edge case?
I had a better reason than performance. I’m a realist. I don’t have the time or patience to write the fastest code in the west. I write code to solve solutions. Functionality first, optimization second. That doesn’t mean that I write slow or hacky code. I just want to get the problem solved first and sometimes it’s easier to write something in straight JavaScript instead of finding a MooTools class or a jQuery plugin, making sure it doesn’t pollute the namespace, assuring that it runs reliably and trying to configure it for my specific needs, even though it was never meant for that.
Sadly, it has been a few years since I’ve been able to really stretch my JavaScript legs and run. From a CTO who banned the use – and all but the mention of – AJAX to projects that were more business rules than user interface I haven’t had just cause to go nuts on the client side. There have been occasional forays into widgets and code snippets but nothing serious. Any real geek should realize that a dearth of reasons to code passionately causes bad things to happen in a programmer’s brain.
The straw that broke the camel’s back was a manager walking over to me, asking me if JavaScript could do XYZ, to which I boldly assured him it could. I sat down, cracked open a fresh TextMate skeleton project and stared blankly at the screen. I had no idea how to accomplish the task, where to look for guidance or even if I could get it done. This could not stand. I needed a core JavaScript refresher. More than that, I needed to cover topics I had never mastered like, say, wholly p0wning the DOM.
It was at that moment that I decided to write my own JavaScript library. Not to have more features. Not to be the fastest. Not to be the most popular. Simply to better understand the language and environment in which it is most often run. A refresher on what I know, a chance to learn new tricks and an opportunity to better learn how to architect something bigger than a snippet.
Things are progressing nicely and when there is a stable base and interface I plan on releasing the code open and free. I doubt it will blow the minds of any seasoned JavaScript experts but already I have some tricks that I haven’t yet found in either MootTools or jQuery. It has been frustrating, fun and frivolous – all the best attributes of any personal code project.
I’ll be clear: I do not recommend writing your own library, framework or other massive code base. Not on a whim, at least. It’s not worth the time to do something that is only half as good as what already exists.
However, you cannot call yourself an expert at anything without knowing how the guts work. Knowing how fuel injection works does not make me a champion race car driver.
And that’s how I’ll end this chapter. JavaScript programmers are not race car drivers.