[dojo-contributors] Module formats for the browser

Kris Zyp kzyp at dojotoolkit.org
Fri Mar 26 00:27:22 EDT 2010



On 3/25/2010 5:53 PM, James Burke wrote:
> On 3/25/10 8:14 AM, Kris Zyp wrote:
>   
>> This CommonJS module standard format is what I am recommending that we
>> use for Dojo source code.
>>
>> So why would we use the CommonJS module format if it necessitates server
>> side wrapping? I know there is extra burden for server side wrapping,
>> but I believe there are several key reasons this is advantageous:
>> * All Dojo modules can be CommonJS compliant modules, and easily be
>> reused on any CommonJS platform.
>>    
>>     
> But the dojo user's modules may not be CommonJS-compliant. It feels like 
> we are setting up a "class" system where the user's modules are inferior 
> or require extra work to reuse. I think one of the powers of Dojo's 
> codebase is that we use the same tools, the same widget base classes as 
> dojo users. Treating their code as "other" does not sit well with me. 
> This also gets to my core beef with CommonJS modules:
>   
I wasn't intended to create any caste system. I just wanted to leave
open the possibility for users to create CommonJS module (delivered with
RequireJS-compatible transport wrapper) or RequireJS modules. There is
certainly a lot of momentum of CommonJS, seems like there would be value
in being able to support both formats, especially since it so closely
aligns with RequireJS (and presumably wouldn't add that much code)
> [start rant]
> I truly believe that CommonJS got the module format wrong. It was wrong 
> to treat the browser as an afterthought, and the async capabilities 
> recently only help a little bit, and they are still second class.
>
> Functions as a module container fit with JavaScript. Returning a value 
> from that function to define the module is also very JavaScripty. The 
> exports thing to me is an eyesore, and it boggles my mind that setting 
> the exported value was not allowed. Sure there is talk of it now, but 
> the APIs for it seem goofy. If it started with a function wrapper, it 
> would be a lot cleaner. I know there is a circular reference cost to 
> return values, but that cost is very small and easy to work around. 
> CommonJS will probably need a setExports at some point and so they will 
> have taken that circular reference cost too. The CommonJS format is 
> trying to optimize the wrong things.
> [end rant]
>
>   
>> * There is less boilerplate that has to be written (and maintained) by
>> us as developers than the load-by-function approach.
>>    
>>     
> I believe this is a premature optimization, trying to avoid a function 
> wrapper style for modules. At least in the browser. As soon as you need 
> to debug, any sort of advantage the non-wrapper solution might have had 
> will be eaten up dealing with setting up some sort of sync system that 
> can work in an async environment.
>
> Plus, the module pattern in JS code (function(){}()); is very common. 
> Given that it is in use, the extra stuff to define a module ends up not 
> being that much different. Functions are the natural module system in 
> JavaScript. Trying to avoid them feels like trying to avoid the braces 
> in JavaScript: that is just how the language worked out. Get used to it.
>   

I am not sure I understand this. If one writes source code that gets
wrapped with the transport format, this shouldn't mess with async
loading or debugging, and the function wrapper preserves the closure
form. Of course if we decide to support directly loading CommonJS
modules (with sync loading), this would basically be a fallback that
would act the same as our current system, and this would indeed be the
untouchables of our caste system.

Kris


More information about the dojo-contributors mailing list