[dojo-contributors] "core dojo", packaging, and the build system

James Burke jburke at dojotoolkit.org
Wed Apr 5 16:10:02 EDT 2006

On 4/5/06, Tom Trenka <ttrenka at gmail.com> wrote:
> > >     1.) do we want to make builds that include things structured
> > > like this?
> >
> > I am very much in favour of this.  When I start on a project the
> > first stage is usually rapid prototyping and Dojo very much gets in
> > the way of my process.  I'd like to be able to include the Dojo bits
> > that I need and get on with the task at hand, at the moment Dojo
> > demands my attention, the package system stands in my way.
> >
> > Now I imagine this is a different scenario for widget authors, where
> > I guess the package system can start to become a blessing as a myriad
> > of files are required, or such is my impression.
> I am also very much in favor of this.  It would help to counter-act the
> perception of bloat as well...it's also at this point (I think) that
> simplified, standard builds such as a build with the base widget system will
> come in very, very handy.

It seems like for rapid prototyping, if we did have a globally
available distribution of dojo on a site than anyone can use (since we
can allow for cross-site includes and preserve the dependency graph),
that would be the best approach.

All you would have to do is do a script src include for 
http://public.server.com/dojo/dojo.js, then just start using
dojo.require() in your code, and you are good to go.

In this scenario, dojo.js is basically the dependency loader that
knows how to deal with dependencies in a package.

I'm not in favor of having raw script src includes for the dojo
packages, since this puts the burden on the developer to understand
the dependency graph. Yes, ideally we should have our packages very
loosely coupled, but in reality some packages will depend on others,
and we could avoid support emails by taking care of dependencies for
the user.

I think this would really give the perception of lightness for dojo:
"all I do is include this dojo.js and I just start writing code.
Nothing for me to install on my server!".

> > >     2.) if so, what would the broad "rollup" files be, and what
> > > would they include?
> >
> > So I think a list of end points would need to be defined, such as;
> > event, io, dnd, date, html (css, dom)... ad nauseam, and then the
> > bare minimum for supporting these modules would comprise the base
> > dojo.js, presumably bootstrap and some of lang at least.
> >
> > I also like the idea of spawning the dependancy system into it's own
> > file, if this is feasible.  This would then allow us to provide a
> > dependancy system which can be picked up by other projects which I
> > count as a win.
> Paul's been reading my mind from across the ocean! :)  I'd count the
> dependency system for other projects as a win beyond count; I can't think of
> anything (other than the kickass modular system that would be newer Dojo)
> that would be better for the community as a whole.

I'm advocating that dojo.js would include the dependency loading code,
since that allows access to all other packages (as long as we have
cross-domain loading from a globally accessible installation or set of
globally accessible installations).

> > >     3.) how would we communicate to users how to use these build
> > > files in conjunction with the package system? or would it be a "non-
> > > package system" build?
> >
> > I guess the blessing I see is that this the only road block is that
> > we clean up dependancies to make libraries stand alone, the package
> > system is one and the same.  If the package API is included these
> > files will continue to have dojo.require and dojo.provide signatures
> > and so everything will Just Work.
> Paul, you frighten me.  You have some sort of machine there in the UK like
> in the XMen movie or something???
> trt

To me, dojo's benefits are (in no particular order):
1) The dependency tracking and loading system.
2) The widget parsing system.
3) Smart contributors making high quality packages, and taking care of
the nasty cross browser stuff.

The dependency tracking is a really nice feature, and I favor
encouraging the use of the dependency code, in particular to new
users. Using a globally accessible dojo installation makes using dojo
a no-brainer for new users. Then it is just figuring out package APIs 
-- getting to coding.

Since the dojo.require() approach allows for a layer of indirection as
to where files are loaded, users could "upgrade" performance by
choosing one of the dojo.js files that in addition to the dependency
loading code inlined some packages. This would then be as simple as
changing the path to the dojo.js script src attribute.


More information about the dojo-contributors mailing list