I have recently started using require.js (along with Backbone.js, jQuery, and a
ID: 646111 • Letter: I
Question
I have recently started using require.js (along with Backbone.js, jQuery, and a handful of other JavaScript libs) and I love the module pattern (here's a nice synopsis if you're unfamiliar: http://www.adequatelygood.com/2010/3/JavaScript-Module-Pattern-In-Depth). Something I'm running up against is best practices on incorporating libs that don't (out of the box) support the module pattern. For example, jQuery without modification is going to load into a global jQuery variable and that's that. Require.js recognizes this and provides an example project for download with a (slightly) modified version of jQuery to incorporate with a require.js project.
This goes against everything I've ever learned about using external libs - never modify the source. I can list a ton of reasons. Regardless, this is not an approach I'm comfortable with.
I have been using a mixed approach - wherein I build/load the "traditional" JS libraries in a "traditional" way (available in the global namespace) and then using the module pattern for all of my application code. This seems okay to me, but it bugs me because one of the real beauties of the module pattern (no globals) is getting perverted.
Anyone else got a better solution to this problem?
Explanation / Answer
IMHO one of the most desirable features one could add to the html standard would be just that: loading a script without executing it right away*. I'd love to have all the code in a script wrapped in a closure, and call it like a function when and if I wanted (maybe even passing parameters to it, for instance using html attributes for that - but that is another story). That would solve many problems in programming for the browser today.
jQuery provides us with the noConflict utility, which is useful if you want to remove the global binding(s), but you have to call it "after the fact". I have no experience with require.js, so it's hard to say whether or not that would be a problem. But it's one of the best ways I know of keeping your programs global-free, and I tend to mimic in my own scripts.
Most jQuery plugins also abstain from creating globals, but they usually require that jQuery (and sometimes $, though it's a bad practice) exists as a global to work correctly - so it's better to use noConflict after all plugins are loaded (and some badly constructed ones might fail even then).
A "last resort" way I can think of accomplishing the same goal would be loading a script as text, using Ajax for instance, wrapping it into a closure before calling eval on it. Cumbersome, but not without its advantages (you could make checks/changes to the loaded script before actually running it - for instance if you load it from external sources). You'd lose some browser protections against XSS though...
About modifying the sources, I agree with MainMa, nothing wrong with that short of the specific pros/cons stated.
*Note: when I say "wrapping all code in a closure", I don't mean the way most scripts already do: create a function and then call it. I meant to create a function and allow another part of your program store it, executing it when convenient. AFAIK there's no "standards-compliant" way of doing that.