Thu May 21 23:12:21 EDT 2009
generate, so I talked about it in the Build system enhancements
As for the loader in general, keep in mind the following things it supports now:
- default loader is sync xhr based, so dependencies are resolved in
the right order.
- the xdomain loader uses script tags to load modules, but it requires
a build pass to wrap the modules in a function, so that we can figure
out its dependencies, load them first, then execute the function that
defines the module. Otherwise, just appending the raw modules as a
script tag means dependencies will execute out of order. This is very
important for dojo.declare calls that reference their superclass as
part of their definition.
- Both loaders support multiple versions of Dojo. They do this by
wrapping the modules in a function wrapper and passing the right
version of dojo/dijit/dojox, other custom modules to the function.
- Both support loading code on demand: dojo.require with
dojo.addOnLoad combination can be used at any time, even after page
load, as a result of clicking on a button for instance.
Some complaints of the loaders:
1) sync XHR sucks. It is slower. Use an xdomain build. Or, we can fix
fix this by making the xdomain loader the default and have it fetch
modules via async XHR. The xdomain loader can handle normal modules
fetched via XHR, and it has the machinery to track and the evaluate
the modules in correct dependency order. The tradeoff for this is:
- You need to use dojo.addOnLoad after doing dojo.require calls in the
top-level HTML page. If you are used to working with xdomain builds
and following best practice to put your code in modules anyway and
only do page init stuff in a dojo.addOnLoad, this should not be a big
deal. But some of our tests have to change.
- We increase the size of dojo.js by including the xd loader's
dependency mapping. I like this in a way because it makes my job
easier, we just go down to basically one loader, but it does have an
increase in size cost, maybe an additional 2KB, gzipped, shrinksafed
I am happy to look into this more if people are OK with the tradeoffs.
2) Debugging sucks with evaled code. Not all browsers support it.
Firefox/Firebug does, and it looks like WebKit is coming online with
it, but IE is still weird. We have the djConfig.debugAtAllCosts mode
that, again, uses the xdomain loader to figure out the right order of
evaluation, then uses dynamically appended script tags to bring the
modules into being. It will be slower loading based on how careful it
is to only append one script tag at a time (IE and WebKit will execute
scripts in network receive order, not in DOM order), but it works for
I would like to make debugging easier when not using debugAtAllCosts,
by trying to load at least syntax errors as a real script tag, that is
being tracked in this bug (thanks to Mike Wilcox for starting it):
Any help on that bug is appreciated. I had problems with IE, but maybe
it was just me.
So these downsides are a result of us wanting proper, nested
dependency resolution. I think they are worth the cost, particularly
since standard Dojo practice is to do a custom build when you are
ready to optimize for performance.
I am happy to entertain switching to async XHR/combining the loaders
if others think it is worth the cost. I would like to make debugging
easier, so thoughts on how to do that are welcome.
But if the solution to the downsides to say "we should not allow
automatic nested dependency resolution", I do not believe that is the
right answer. It is one of the main differentiators for Dojo, and it
makes it possible for us to scale up to very large applications.
More information about the dojo-contributors