[dojo-contributors] Asynchronous Module Definition (was Re: [CommonJS] Another idea on unifying Transport/C and /D)

Kris Zyp kzyp at dojotoolkit.org
Sun Oct 10 18:06:37 EDT 2010

 (Added dojo-contributors as cc since it affects current module
refactor, response inline)

On 10/9/2010 10:31 PM, James Burke wrote:

> > On Sat, Oct 9, 2010 at 11:56 AM, Kris Zyp <kriszyp at gmail.com> wrote:
>> >> On 10/9/2010 12:49 PM, Kris Kowal wrote:
>>> >>> "ensure" is useful in both contexts.  "define" should
>>> >>> not be available in Module context because it does not make sense to
>>> >>> have a cycle in the layers of the architecture.
>> >> True, that's good point. So could we have a define.ensure for scripts
>> >> that are outside a CommonJS free variable context, but have
>> >> require.ensure that can be accessed from the require free variable
>> >> inside a CommonJS context (inside a define factory or commonjs module),
>> >> both aliasing the same behavior? That would seem reasonable to me.
> > I am hesitant to make another global in <script> space for define.
> > <script> space is even more sensitive to globals than the usual places
> > CommonJS modules are run, since all the scripts loaded via <script>
> > share a global space. I prefer the global impact for <script> to be
> > very small. Right now, it is just "require".
> >
I am not suggesting adding "define" to "require", I am suggesting
replacing/removing "require" with "define". There would still only be
one global defined. There's no reason we ever had "require" as a global,
and it is time to choose an appropriate global.

Of course, I understand that RequireJS can't eliminate "require", since
it is a core API for it. However, needing to have two globals is hardly
going to get much sympathy from me, especially considering that the
whole module system eliminates the need for developers to be fighting
for globals at all. Back in the ol' days when we used archaic namespaces
hung off globals this was a bigger issue. Now we could have dozens of
globals without impacting the module system. EcmaScript itself defines
dozens and the typical browser environment has hundreds of globals. Plus
globals used without any community coordination (libraries grabbing
common names as globals without namespacing) is the biggest source of
possible conflict, but this is completely the opposite, it is totally
being done as a community, and is exactly the *right* way to establish
globals. One or two (community ascribed) globals should hardly be a concern.

> > I also do not think define.ensure makes sense -- it really means a
> > kind of "require" vs a "define" -- the script requires that these
> > other scripts/modules are available before running the function.
Its no less logical than require.def, whose purpose is to define a
module. This is all about frequency. If every single module using the
module definition API, but only a call or two that does the initial
require (require([]) or define.ensure()), it makes sense to give the
more frequently used form the most elegant logical API. Or we could have
a "define" and have a global "require" like RequireJS's.

But RequireJS doesn't even implement require.ensure, does it? It doesn't
seem like this would affect RequireJS.

> > require.def vs require.define: what Kris Zyp said, and it just less
> > typing, which is nice for something that will be hand-written. I
> > consider it like var or fs, although I understand the "use real words"
> > approach this group has tried to follow. Originally I was happy with
> > just:
> >
> > require('optional module ID', [dependencies], function (){ definition
> > function }).
> >
> > Which would also work for an ensure-like behavior as well as handling
> > async module definitions, with the require('string only') form being
> > the traditional require. I appreciate that it may be seen as too much
> > to do as part of one function signature.
> >
> > If it made a *strong* difference to actual sync module proposal
> > implementors or people seriously considering implementation, then I
> > could put in an alias for require.define to require.def, but I will
> > likely still support require.def due to deployed code/existing users.
I think the main reason this is worth considering is that it affects
*every single* module (and the byte count thereof, which quickly adds up
for apps with many modules), so it is worth taking a hard look at what
is best here even if there might mean some API change pain.

-- Thanks, Kris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20101010/085d7d4c/attachment.htm 

More information about the dojo-contributors mailing list