News

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

JSLoader Provides Shared Sourcing of JavaScript Libraries

Posted by Rob Thornton on Nov 02, 2007

Sections: Development
Topics: Javascript ,; Java ,; Web Development ,; Dynamic Languages ,; Languages ,; Programming ,; JSLoader

JSLoader, a non-intrusive “JavaScript-on-demand” packaging convention has been released to help manage the growing complexity of JavaScript libraries and their dependencies.

JSLoader is described as a zero-install solution that will allow websites to use new toolkits without learning how to install them. This type of solution will allow browser and proxy caches to be more efficient and will prevent multiple sites from having to maintain their own version of a toolkit. The creators of JSLoader answer the question of why it was created:

rapid adoption, and easy prototyping from a hosted location (zero-install)

shared sourcing of files in an enterprise setting (which helps caching, and version control)

a dead-simple way for developers to include the assets, which will drive adoption and give them just enough value to not want to download static copies of the code (a maintenance nightmare)

JSLoader is not the first library to seek to fill these needs. Dov Katz, one of the creators, acknowledges this and lists OpenJSAN and OpenMV as similar libraries but says they didn’t quite fit the bill.

What I needed when I was tasked with this is a production-ready developer-friendly solution for an enterprise environment. My main goal was to make it easier for developers to use scripts that they should not be installing on their own. Until all scripts were ready for use via OpenAjax’s Hub or OpenJSAN, the JSLoader system provided enough benefit to allow us to proceed in an enterprise-grade production setting.

An interesting discussion developed at Ajaxian. Numerous related implementations are mentioned, from Csi to jsPax. Katz points out that much of the discussion boils down to knowing what it is and is not intended to be.

At the most basic level, this is nothing more than writing the same script and style tags on the page without having to know which ones to put and in which order. That alone has made it useful for my stakeholders. It’s not intended to solve the namespace problem, and for the majority of cases in an enterprise setting things are all eventually in your browser cache since multiple intranet sites share the same loader and hosting of assets.

100% agree. It’s important to know (1) what this is, and more importantly, (2) what it’s not.