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

James Burke jrburke at gmail.com
Tue Oct 12 13:22:56 EDT 2010


On Sun, Oct 10, 2010 at 3:05 PM, Kris Zyp <kriszyp at gmail.com> wrote:
> 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.

My concern was more for browser code that gradually adopts the
require/define approach. I believe that will allow for quicker/broader
adoption if existing code can use this new functionality gradually, so
fewer globals are better. I also agree that if push came to shove,
then two vs one global is not that much of a change, but the proposed
renaming to me did not seem to give that much benefit to warrant
another global.

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

I believe require.def is more logical than define.ensure. require.def
implies you are defining something that obeys require's rules.
define.ensure does not define anything. But this is a bit of a
bikeshed.

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

I have not implemented it because no one has asked for it when using
RequireJS, and I think it is inferior to the require([]) syntax that
RequireJS provides. However, if it enabled widespread async module
adoption (vs RequireJS require([]), then I would implement it, since
it is a subset of what require([]) can do now.

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

I do not believe byte size count matters for performance reasons (with
an optimized, minified delivery of modules with gzip, it will be
unnoticeable), but I appreciate wanting the cleanest API.

I am voting "no" though, I do not believe it buys that much for the
following reasons:
- inertia. Mostly my personal inertia. It does not feel broken to me.
- I also like the single global. It still makes sense to me that an
ensure stays on require, or even better, just uses require([]) as used
by RequireJS. That means the define name space just defines an async
module, and an async module implementation still needs to implement
something for "require".
- I like that require.def implies that it obeys require's rules.
define seems to float out in the ether.

If others feel strongly, that require.def is just wrong, then I can
support a define that maps to require.def in RequireJS. But others
should speak up soon, as in the next couple of days. I want to move on
to implementations and adoption.

James


More information about the dojo-contributors mailing list