Coding Horror covers some general criticism of Javascript libraries reminiscent of a few criticsisms I eluded to in previous posts such as “Javascript: The Quickening” and “Yahoo’s YUI Drag and Drop Module”. I think it could be stretched to other languages as well however as javascript has been a focus of mine recently (and many others) I thought I would explore some frustrations with working with the YUI library (as well as some other libraries) I have had recently.

Firstly, a point in reference to the Coding Horror post. The veneer of documentation can be a trap. The YUI library has more documentation than most, including API documentation, general overview documentation, cheat sheets and many examples. All of that and seasoned OOP javascript developers can still find it quite difficult to use parts of it for work more complicated than the basic examples provided in the documentation. I am interested in exploring why this is.

I find that many examples are often not coded to a standard that would stand up to much scrutiny except somehow examples seem to be exempt from quality control. Procedural code seems to be generally preferred ‘to keep things short’ and they use short cuts such as inlining everything in your HTML which ignores the real issues that go beyond stitching a few API calls one after the other.

The more complex issues in using libraries to solve complex problems are ignored. Trying to get javascript libraries in particular, playing nice with other code can be difficult. Controlling when the code is called and when things occur are complex issues however looking at any Prototype examples you may think that randomly pasting script blocks throughout your code is a sane thing to do.

Another issue I find YUI and most other JS libraries have is not all files clearly state which other files they are dependant on. This appears to be because such documentation is not uniformly enforced across the library (This is a feature of single author libraries as well, I find).

With Javascript unable to natively define explicit dependancies it is more likely to fail with an obscure error or worse still run but incorrectly. It is a time-consuming practice to work through finding all files it may need from the library and all assets it may be relying on (CSS, images etc.). And generally nothing works at all intended until you get it just right… Javascript in particular is often dependant on the order of the includes as well.

To my mind, dependancy tracking is a key facility of documentation whether it be derived from package names or calls to ‘include’ type functions (see my earlier post for the blurred line between documentation and code).

The namespacing efforts of YUI and Dojo; and Dojo introducing linkers and the ability to dynamically include required scripts we may see this improve but until more mature solutions exist we are doomed to some very frustrating hacking – contributing to the mug’s game that is web development at the moment (a topic for a separate post).

Stumble it!