[dojo-contributors] Module formats for the browser
rcgill at earthlink.net
Tue Mar 30 07:28:07 EDT 2010
> -----Original Message-----
> From: Kris Zyp
> On 3/29/2010 2:05 AM, Rawld Gill wrote:
> >> -----Original Message-----
> > I am strongly against "the CommonJS format with a server side module
> > wrapper":
> I think there is already consensus that we won't use this for Dojo's
> The CommonJS transport wrapper is LBF and basically already works with
> RequireJS, so I presume you aren't say that we should somehow try to
> ensure that all user modules are completely hand-coded and that no one
> ever uses any bytes that originated from any automated tool. Not sure how
> we would police that ;).
Right, I am not saying that. I do believe that all
dojo/dijit/[probably]dojox modules should follow the same module pattern,
dojo.def(<module-name, optional>, <requirement-vector>,
//requireJS uses "require.def" instead of "dojo.def"
//module-definition can be any data type; typically, it's a function
> > At this point, I believe I can produce a version of dojo that can be
> > loaded by *either* the asynchronous loader *or* the current
> > synchronous loader with a couple of minor, backward compatible, mods.
> Does this differ at all from James' approach and his multi-build setup?
> Are you suggesting something different than him?
I think James and I are in agreement on the big picture items, but place
priorities differently on some of the details...
I think trying to maintain a converter script to automatically move the code
base from the 1.x dojo.provide/require pattern to the LBF pattern it too
error-prone and yields non-optimal code:
* James already mentioned the possibility of putting yet more build pragmas
in the code to handle the "manual" steps. The code base is already getting
very ugly--and, therefore, more difficult to read and maintain--with the
recent proliferation of build pragmas.
* Some changes (e.g., i18n and dojo.declare) require some delicate editing
and I would be loath to do these changes automatically since continued
development may cause the automatic process to produce defective code.
* I don't see any mention of testing the converted code. Although not hard,
converting the tests takes some effort and ought to be done.
* Assuming the same code base (not including the bootstrap/loaders) will
work with both loaders, I don't see a down side to making the change.
The bottom line is that you can make LBF modules load synchronously; you
cannot make the current code base load asynchronously--at least not with the
script-inject approach. Clearly, having a single code base is better than
I advocate dojo taking responsibility for the two loaders as opposed to
saying "use the requireJS loader". I think dojo should be released with two
separate, independent bootstraps/loaders--one each for the old synchronous
loader and the new asynchronous loader.
I sense that a synchronous plugin to the asynchronous loader would not be
hard, and would allow users to continue to code with both
dojo.provide/require and the new asynch loader, allowing an easier
transition. But, I haven't thought about this carefully.
I think we should make it a priority to minimize the size of the
asynchronous bootstrap and the base modules. This is perceived as very
important by some users and dojo has taken hits on this issue before. I
believe I've made some good progress here, but I'm still working on this.
Therefore, I advocate "biting the bullet" and converting at least dojo and
dijit to the LBF module pattern, en masse, immediately after some release.
This is going to take some commitment from everybody to take a look at their
code. I am happy to provide the conversions for dojo/dijit and test dojo (I
can't commit to testing all of dijit) on my machines. But for such a change,
module owners will need to take a careful look.
More information about the dojo-contributors