Keep JavaScript Simple
By Peter-Paul Koch
On a few occasions, Java programmers mailed me the URLs of the JavaScript libraries they had created, asking me to take a look at them and suggest improvements. I reject the whole idea of JavaScript libraries, so I never answered these mails.
They made me think, though, “Why do people write complex JavaScript libraries?”
Improving JavaScript
The most revealing purpose of a JavaScript library I ever encountered was “to make this-and-that Java functionality or structure available in JavaScript.” The hidden assumption is that JavaScript isn’t working properly. It should be improved. It really ought to be Java.
For some reason, people think JavaScript is simple. Sure, writing “Hello World” in a form field is simple, but creating an accessible, usable, and cross-browser compatible W3C DOM script is anything but.
Nonetheless, the misperception that JavaScript is simple (therefore low status) still survives, especially among “hard” programmers. Some of them don’t find it necessary to understand JavaScript. Instead, they want it to understand them. They want it to behave like the languages they already know. They want it to be a complicated, high-status language like, for instance, Java.
These programmers don’t get the point of JavaScript but are arrogant enough to think they get it better than anyone else. Even worse, they write JavaScript libraries.
They should remember that JavaScript is not Java. It is a programming language in its own right with its own purpose, functionalities, and structures. It does not need to become Java either. If they want to write Java they should write Java. If they want to write JavaScript they should learn how to write it properly.
Size matters
When you add a script to a Web page you create a small, local effect that enhances the usability of that particular page. That’s the purpose of JavaScript. Such a small effect requires only a small script.
Unfortunately, library writers don’t understand this. Every JavaScript library grows and grows and grows until its sheer size and download time bears no relation to the rather meager results it delivers.
I once tested the DynAPI library by installing one of its pre-packed code examples that makes a layer bounce through the browser window. I then measured the weight of the required JavaScript files. The download necessary for this simple effect was nearly 40K!
Any competent JavaScripter could obtain this effect with 1K of code, if not less. I concluded that the DynAPI programmers, though they know far more about programming than I’ll ever learn, are not competent JavaScripters.
The huge size of libraries is caused by diligently construed layers of programming on top of other diligently construed layers of programming. That’s an excellent strategy for creating large applications, but in a Web environment, it’s like using heavy artillery to kill a fly.
Objection
Sooner, rather than later, library writers smugly mention their object-oriented approach. Lo and behold, they ride to the rescue of poor JavaScript! It is not object-oriented enough—a truly heinous heresy.
Browsers automatically create an astonishing amount of objects—for instance, the entire W3C DOM tree. These objects are already there, though, so they don’t count towards making JavaScript more object-oriented. To prove their OO orthodoxy, library writers are forced to inflict their own flocks of obscure objects on an unsuspecting world.
Again, the writers refuse to consider the structure and purpose of JavaScript. I feel that JavaScript’s object-oriented approach mainly serves to keep access to the DOM simple. In any case, there are more than enough objects to create small, localized effects on Web pages. No one needs yet another bunch.
Finding fault
The purpose of many script libraries is to eliminate browser differences. This is usually praised as a great advantage, but to me it is their worst disadvantage.
These libraries cause the same problems as WYSIWYGs. If you stumble upon a difference not covered by the library because, for instance, a browser doesn’t behave as the programmer expected, you’re out of luck, especially when you’ve only worked with libraries and don’t have the faintest idea how to work with browsers.
Even if you do know something about browsers, it’s very difficult to find the offending line of code because it’s buried in some vague object at the lowest level of programming, the proper place for such aberrations. Even if you find it, chances are you have to scramble the library’s browser detect object first.
The documentation doesn’t give a clue either. Mere browser differences are not object-oriented enough to merit inclusion in these pages devoted exclusively to the cleverly crafted library structure.
Writing simple scripts
When I create a JavaScript, I write procedural code: do this, then that, then that, then end the script. Only when a certain action occurs twice or more do I create a separate function for it. This keeps my scripts simple, clear, and easy to update even for another Web developer. It also keeps my scripts short because I don’t need a herd of overhead objects.
So my scripts aren’t reusable. I’ve never seen this as a problem. The real core of the script (finding the position of an element, accessing a DHTML layer) is reusable. I only have to copy a few key lines to get it working on any page in any browser that supports it. I usually document and publish this core code so that it’s readily available to all.
I have to rewrite the unique parts of the script (doing something with the position of the element, changing the styles of the DHTML layer), but I’d have to do that anyway, even when I’d use objects and libraries.
Don’t bother
So I disagree with all purposes of JavaScript libraries. I want a clear view of the browsers my script runs in, of their problems and quirks. My view should not be obstructed by a programming layer that is far too large and complex for the simple effects I need, that hides crucial lines of code deep inside a convoluted clutter of obscure objects, and is a monument to the absurd notion that JavaScript really ought to be Java.
My advice to library writers is: Don’t bother. Keep it simple.