Related to the topic I was emailed a link to http://en.wikipedia.org/wiki/AJILE which is yet another entry into the fray
and to recap the previous entries:
http://www.jsloader.com/
http://openjsan.org/doc/c/cw/cwest/JSAN/0.10/lib/JSAN.html
http://www.jspax.org/
http://csi.origo.ethz.ch/
http://amix.dk/blog/viewEntry/174
http://dojotoolkit.org/support/faq/how-does-dojo-require-work

So there are a few choices. What directory structure are you using? Personally I use /jslib/com/.. following the reversed domain approach. Is everyone using closures?

(function(){
if(typeof(window.com)===”undefined”){window.com = {};}
if(typeof(com.mydom)===”undefined”){com.mydom = {};}
if(typeof(com.mydom.myClass)===”undefined”){
com.mydom.myClass = function(){
var myPrivVar;
return {
myMethod:function(){
var foo = myPrivVar;
}
}
}();
}
})();

Ex:

function needsScripts(arg1) {
var div = AJS.DIV();
alert(div);
}
needsScripts = onDemand(needsScripts, ['AJS.js', 'greybox.js']);
needsScripts("Cow is mad");


The xdomain Dojo loader is a script tag loader. It requires a build process to prep the JS files for xdomain loading, but the benefit to doing so means that you can load the files after page load, and you get dependency resolution.

From what I can tell, Dov Katz’s JS Loader uses document.write only, so this will not work after page load. I also believe it will result in the same sort of “freezing” of the page that you can get with the regular XHR-based dojo loader if you try to load lots of modules as the page is loading.

The Dojo xdomain loader makes it possible to load all of the JS libraries from another domain, even a CDN, like the JS Loader tries to do. This means the xdomain loader delivers on the benefits in the “Why JS Loader” wiki page: No local installation of JS library files needed: add a script tag and go. You can use all of Dojo from AOL’s CDN using this approach. Not everyone will want to rely on a 3rd party site for their live site needs, but it sure makes prototyping and exploration easier. And you can always install an xdomain build on your own network, to at least get the async/more domain connection benefits.

I generally prefer requiring as little configuration to specify what needs to be loaded for a library. I think Dojo does good in this respect, requiring just a base URL to give the root of a library, then relying on a convention to load the rest (dojo.require(“foo.bar”) maps to http://base/url/foo/bar.js). Having good dependency resolution code also helps in this case. I know that is not a goal for the JS Loader, but I think it would help get away from needing the extra incr files.

For more info on some of these loader topics, I suggest checking out my Ajax Experience presentation on the xdomain loader, and my blog post talking about the YUI loader.

The latest jQuery 1.2 can load scripts via dynamic script tags (via jQuery.getScript). It does not have dependency resolution, but does the basic script loading, and it works after page load. It relies on script.onreadystatechange/onload to know when the script is loaded. I thought onreadystatechange was unreliable in a cached situation for IE 6. Although, I heard that a few years ago, maybe it is not true anymore. Still something I would like to investigate.

This is an interesting subject, I hope to see more discussion in this area.

It would be easy to modify it to hit a servlet with all the “modules” to load and have it merge the JS on the fly and send it back in a single packed, Expiry-controlled response (for caching). At it’s core, it’s nothing more than writing script tags for you.

As I’ve pointed out, if you’re an enterprise (or Google, Yahoo, or some other large distributed content network) single points of failure are not a concern. You’ve engineered around them. The same reason I see sites using YUI hosted from Yahoo without worrying about yahoo going down.

I would *not* recommend relying on jsloader.com for the same thing :), but if, for example Google or Yahoo promised to host things resiliantly, and they’re able to pull it off, and they offered free lib hosting for libraries, developers would be able track use of their libraries, and maintain them much more easily than having people freeze them in time and use them locally. (imagine a google code, hosted libraries, google groups, and google analytics power pack offerring with the ability for google to get a first-hand view of the emerging AJAX libraries)

If you took a clone of the “repository” filesystem and replicated it on every web server hardware in your enterprise, you might benefit from not having to worry about individual sites/webapps installing the libraries on their own, and benefit from an always up-to-date repository of libraries. (Value for developers in ease-of-library use, and Value of infrastructure teams in knowing what’s deployed in their environment).

That stuff was done way back when webos.com was still alive and kicking, so it’s not exactly groundbreaking..

Sample:
http://tapper-ware.net/devel/js/csi/csi.htm

Project Page:
http://csi.origo.ethz.ch/

The hosted solution works sometimes (its on load balanced regional pairs of highly available servers) the local one is also an option.

This eliminates any single point of failure concerns, as well engineered infrastructures do, in general.

If the globally replicated filesystem is down in general, I’d say you have more problems to worry about than your ajax libs!

Going back to “what it’s not” from my previous response. It’s not a dependency management system, nor is it a synchronous package loader or namespace management system. It’s just a way to abstract knowledge of asset location to make it easier for developers to use libraries. I’m looking at something along the lines of the efforts in OpenAjax Alliance’s space as a long term strategic solution to the problem this tool tactically solves.

Actually, I think that someone has used the dojo loader to load other things as well (maybe mentioned above).

Anyway, it _is_ a great idea. For instance my web IDE would load twice as slow if I had to load all the stuff at once, instead of deferring, say, the code editor until the first time someone open a function.

Good idea, good competition. keep’em coming :)

PS