[dojo-contributors] Asynchronous Module Definition (was Re: [CommonJS] Another idea on unifying Transport/C and /D)
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
>> 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
> 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
- 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.
More information about the dojo-contributors