BT

JSLoader Provides Shared Sourcing of JavaScript Libraries

by Rob Thornton on Nov 02, 2007 |

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.

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

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT