[dojo-contributors] Module formats for the browser

James Burke jburke at dojotoolkit.org
Fri Mar 26 01:49:54 EDT 2010


On Thu, Mar 25, 2010 at 9:27 PM, Kris Zyp <kzyp at dojotoolkit.org> wrote:
> 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)

OK, I was reacting to what I thought was a suggestion that our Dojo
modules authored and stored in Dojo source control as CommonJS
modules. I do not believe that is the way to go.

But being able to consume CommonJS modules that others write and are
delivered from their servers in the CommonJS Transport format, I
believe we can support that. I was hoping to build support for
consuming the Transport format in RequireJS (basically converting that
format to the format RequireJS handles internally). If the Transport
format gets too weird then it might not happen, but so far what you
and others have proposed seems doable to support.

But from what I have seen of the CommonJS Transport format, it is not
something I want to hand-author (too verbose on a module-by-module
basis, optimized for server generation), so I do not believe we should
code our modules in the CommonJS Transport format. Plus, it requires
the use of exports, which makes me throw up in my mouth every time I
see it.

We could provide a translator that someone could run over the Dojo
modules as coded in RequireJS format to convert it to the CommonJS
Transport format, particularly once CommonJS allows setting exports.

How does that sound?

>> 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.

Right, there needs to be the extra step of converting the code to a
"transport format" because the basic CommonJS module format is
insufficient for browser use. The CommonJS module spec from the get-go
should have used function wrappers, because those are the natural
module containers in JavaScript, and async needs should be possible as
part of the basic CommonJS module format. If that approach was taken,
then instead of needing exports, the return value of that function
wrapper could have been used to define the module. And needing a
"transport format" or an extra require.async would not have been
necessary (if you can live with modules IDs in the definition).

I find the need for an extra "compile" step for the modules to a
Transport format to work in the browser a failing of the CommonJS
module spec. It takes more work to use CommonJS modules in the most
widely distributed JS environments. I disagree with that. And the
counterargument for designing for the future or competing with
"simpler" schemes (like perhaps python or ruby) does not resonate at
all with me. To me, those are arguments are ones that wish JavaScript
was different than what it is. It is not perfect, but it works, and
having a simple working system, particularly in the browser, trumps
those other desires. It is why JavaScript is where it is today.

But I am monologuing again. I apologize. I try to restrain it, as I
can appreciate that I could be wrong, most people do not care about
this, and I probably care too much about it. Any counter-balance you
can provide is welcome.

James


More information about the dojo-contributors mailing list