Thanks for your comments. This test was an evaluation of JavaScript libraries *OUTSIDE* of WSS/MOSS. The (possibly erroneous) conclusion is that *IF* you’re going to use a library, use one that is lighter and faster (since as you pointed out, and we all know, SP has a metric @$$ton of .js already).

As far as “class structures,” SP is basically all up in the global namespace, there aren’t really classes in the classical sense. jQuery (and other good libraries) however tend to follow a single object, usually a factory function responsible for collecting DOM nodes to apply methods to.

Yes, SP’s js is a mess. All the more reason to use modular patterns and/or a library. Stay out of the global namepsace to avoid conflicts.

I for one *WILL* use a library when I’m working with a sloppy DOM like SP’s and most of the users have IE {shiver}. I just don’t have the time to burn troubleshooting cross-browser issues or creating specialized collection routines looking for nodes without classes, ids, or predictable structure.

Like any library choice, it’s a trade off, and after the first time someone caches your library file, I’m guessing one that’s worth it in the long run. After all, it’s only milliseconds for my user but it’s weeks for me–call me selfish.

Given the vast multitude of javascript libraries that are loading with every page view–particularly in MOSS–how can we be sure that there wouldn’t be far more errors due to duplicate function or variable definitions, or slower execution in general due to the extensive class structures loaded in memory?

A lot of these web parts will interact without issue but I have not personally tested that combination. In my workshop, we put 3-4 of them together with good results, but they were tested that way.

Chrome beats all comers, hands down. I’m going to start doing all my demos in Chrome :)

Very good point. I can’t find an updated version, so I’m trying to rebuild using theirs.