3

I just notice that there is some changes in the jQuery source in it's library wrapping technique. As I remember in version 1.4 they used this library wrapping:

(function(...){
   var jQuery = function(){
    // some code
   }
   // other code    
})(...);

and now in 1.6.x:

(function(...){
   var jQuery = (function(){
      var jQuery = function(){
        // some code
      }
      // other code 
      return jQuery;       
   })();
})(...);

Just a thought, did anyone happen to know what are the benefits of this changes (the wrapping technique)?

Habib Rosyad
  • 332
  • 1
  • 5
  • 15
  • This confuses me. You have just posted the inception of closures. – Seth Oct 15 '11 at 00:53
  • what closures? it just local variables there... You can see those in jQuery source... I'm not posted the whole code though, and I just wanna now the benefits of it's changing library wrapping technique... – Habib Rosyad Oct 15 '11 at 00:56
  • The first `var jQuery` basically allows you to have private variables. I would assume that anything inside the second `jQuery` would be initiated unless you called it, but I'm not 100% sure about it. I know the first `jQuery` call allows what's inside to be private until you `return` it. – Seth Oct 15 '11 at 01:38
  • Yeah, basically, both version of the code produce private variables to prevent polluting the global namespace with unnecessary variables (that's what library wrapping are). In the second code, as the first `jQuery` initiated, it return the second `jQuery` as result. So I thought the first code is just more direct than the second, and wondering where the benefits of this, as for me every code must have a reason behind it... :) – Habib Rosyad Oct 15 '11 at 02:14

1 Answers1

0

I don't think this is exactly "library wrapping" per se - the outer anonymous function is still wrapping the entire library. I think what you're seeing here is that parts of the jQuery code, and in particular the part that defines the core functionality, use the Module pattern to keep portions of the code in a limited scope.

For example, if you look at the core.js source file, you can see that lines 4-77 define a ton of variables - you can see why you wouldn't want all of that hanging around in the variable scope of the rest of the library. The module pattern helps to minimize conflicts and confusion in a large body of code, and at a guess I'd say that the reason they started using this pattern after v.1.4 is that the codebase got larger and more complex. So I think what you're seeing in the final library is not tighter code from an optimization standpoint, but more robust code from a maintenance standpoint.

I'm not a jQuery developer, so of course this is all guesswork. But it seems like a reasonable explanation.

Community
  • 1
  • 1
nrabinowitz
  • 55,314
  • 10
  • 149
  • 165
  • I stated it as "library wrapping" as mentioned by John Resig himself in his upcoming book "Secrets of the JavaScript Ninja" (I have the Unedited Draft version), and it's exactly mean like that, the outer anonymous function literally wrapping the entire library, and introduced only the necessary variable (jQuery) to the global namespace... hmm, maybe it just another kind of module pattern implementation... I'm agree with your point that maybe the last code is written just for easy maintenance in the future. It just made me curious, that maybe it also have some benefits in optimization... – Habib Rosyad Oct 15 '11 at 05:19
  • All I meant was that the inner anonymous function isn't part of the "library wrapping", so much as it's part of the internal library code. The library wrapping hasn't changed in your two examples. – nrabinowitz Oct 16 '11 at 04:20