BT

New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

JSLoader Provides Shared Sourcing of JavaScript Libraries

| by Rob Thornton on Nov 02, 2007. Estimated reading time: 1 minute |

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:

  1. rapid adoption, and easy prototyping from a hosted location (zero-install)
  2. shared sourcing of files in an enterprise setting (which helps caching, and version control)
  3. 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.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and dont miss out on content that matters to you

BT