What we need to make a jQuery script loader the right way… as part of jQuery itself.

by wforney 16. November 2011 10:41

For a while now I’ve been kicking around the idea of a jQuery script loader. There are several that take the problem halfway there, but usually they are implemented in a way that makes them harder to use than they need to be, or they are lacking certain key features.

Here is what I think the loader would need to be capable of in order to be done right. It should:

  • be AMD compliant
  • handle nested dependencies
  • handle composite/combined scripts (scripts that contain other modules that could be loaded separately)
  • allow for a way to check if a script is loaded other than its own internal index (like !!window.jQuery)
  • allow dependencies and composite modules to be defined on the script itself (optionally support a self-executing wrapper)
  • not allow itself to be stomped on if it is loaded multiple times via script tag or other means

Ideally this should be integrated into jQuery itself. Boris Moore has developed a loader that does some of these things called jsDefer but it has some issues at present. Its composite script support does not really function as the documentation would lead you to believe and the script definition process for wrapped scripts is lacking a way to name nested combined scripts easily (or it just has a bug).

There is a loader in the Ajax Control Toolkit that elegantly handled most of these issues, but few knew about it and less used it. However, it is not AMD compliant and has been deprecated and fallen out of favor in most circles due to its tight coupling the the toolkit and the rise of ASP.NET MVC.

So, it needs to be built into jQuery. It makes sense to do so because jQuery has over half the functionality needed by the loader already baked in. It shouldn’t really be a plugin because you should have one consistent way of loading all your plugins. But if it is to be baked into jQuery itself, jQuery needs some modifications. At the moment jQuery does not check for itself when it loads and there are many versions floating around in the wild. When building modular solutions there is a need to load jQuery multiple times on a single page and you cannot guarantee that widget A uses the same version as widget B. So to overcome this we need changes.

jQuery should:

  • defined in a feature manifest for each version, or
  • check for its own existence, and if found
  • check for its version, or
  • check for prior existence of each feature, and
  • override the feature if it is an older version, while
  • not stomping on itself, thus preventing plugins from being trashed (extend, don’t assign)

Anyway, these are just my ideas around a built in script loader and how jQuery needs to change to support this type of scenario, which is becoming more commonplace.

Tags: , , , , , ,

jQuery | JavaScript

Comments are closed

Calendar

<<  August 2014  >>
MonTueWedThuFriSatSun
28293031123
45678910
11121314151617
18192021222324
25262728293031
1234567

View posts in large calendar

Month List

Page List

Email Subscription


RecentComments

Comment RSS

VSAchievements

( Points)