Contributors, please read
I've developed iMars JSlib mostly as a personal project, but it's matured enough for others to possibly show an interest in it. Being an interpreted language, little is done to "build" the library. Just used the included Makefile and you'll be all set.
If you're a developer and would like to contribute patches back to JSlib, I have a private CVS server and CVSTrac web site which I can manually grant you access to, in order to facilitate our exchanges.
In the interest of clear, explicit inline documentation without penalizing production release performance, I've implemented an efficient, yet robust pre-processor based on "cpp -P" and "sed". When you run "make package" (or "make all" which uses all available modules) you actually pass "src/*.js" through "cpp -P" which removes all comments, reduces non-string whitespace to a single space each, and then through a regex with "sed" to remove indentations left by cpp. The result brings well-documented code down to about 30-50% of its original size while keeping all original function and variable names, and keeping each original line of code separate to help with the occasional debugging of released code.
While it's in no way competing with the likes of the YUI, it is extremely small (and also fast!) for what it provides, which is what I was looking for.
CONVENTIONS AND PHILOSOPHY OF THIS PROJECT
1. The features themselves are all within the "imars" object, to keep the global namespace clean. While the "imars.use()" function could be used to add references to deep functions and objects in current/global namespaces, it is only provided as a convenience to the end-user webmasters; parts of the library itself always use full names to refer to other parts of the library. This is leaner on memory and avoids any possible collision with third party code.
2. For features which rely on some CSS for their functionality (i.e. CSS which would never need to be modified by web designers making use of the feature) the style is applied from within the JS code to avoid depending on external CSS.
3. In the spirit of unobstrusive JS, most features scan the body "onLoad" for specific tag names, ID's or classes to apply their event handlers without cluttering XHTML with JS code. In the spirit of Web 2.0 interactivity, those features should be capable of re-scanning the body or a specific portion of the DOM tree later during the page's existence, to keep behavior consistent on modified or inserted contents.
4. For production use, developers should use "make package" which strips and combines the desired source files in an appropriate sequence into a single JavaScript file. That way, a single browser request will load all the needed features, and NONE of the features that aren't needed. Keeping I/O to a minimum is important!