In: Columns > Keep It Simple
Published on July 25, 2003
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.
A 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
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.
My advice to library writers is: Don’t bother. Keep it simple.