alex at dojotoolkit.org
Wed Apr 5 00:40:21 EDT 2006
So we've had a couple of discussions in the past about how we're going
to reduce package sizes, usually as a response to my abject horror at
our build sizes when I make a new package.
While my concerns are usually overwrought there is a perception "out
there" that Dojo is too big and (often wrongly) that other toolkits are
lighter. While this is pretty clearly bogus, it is true that we have a
lot of cruft that is in need of cleanup/removal. Thus far we've been
very reticent to remove things. I think this needs to change.
Compounding the problem is that many large users and potential users of
the toolkit are asking "when is it going to settle down?", to which I
usually reply "it's only got to change more, and hopefully faster".
This isn't what they want to hear. We're only at 0.2.2, but already our
users want it both ways.
We have several project goals that are widely compatible, but which
impact the overall size of Dojo:
2.) ease the burden on users and reduce the cost of using JS
3.) provide a place for the JS community to work together
Generally speaking, we've come up w/ some consensus around API
* only remove APIs after sufficient warning
* unit test or face my wrath
* provide back-compat shims for one major rev
* break out like functional areas into namespaces
* remove APIs that no other Dojo code is actually using
But applying these policies equally amongst our modules only makes sense
if they are equally stable. They clearly aren't, and the strong bias
toward "add but not remove" in these policies leaves us in a position
to accrete code. Every back-compat shim and unused API is added weight.
So we need some sort of socially enforceable contract(s) that will:
1.) help us kill old/bad/renamed APIs more quickly and with less guilt
2.) allow module maintainers to fight bloat in their own modules
3.) allow us to collectively finger-point when modules "go big"
4.) allow us to provide builds that "feel smaller" and rely less
heavily on the package system
Obviously, some concerete steps are being taken today to reduce bloat in
many APIs, namely:
1.) a rewrite of the animation system (started)
2.) some good work in the utility namespaces at breaking things up
3.) better "wrapper" APIs to reduce the size of calling code
But I suggest that until we come up with some way to agree on policies
that can help prevent global bloat, we'll never feel empowered to be as
ruthless as success demands.
alex at jot.com
alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 188 bytes
Desc: not available
Url : http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20060404/a3ab1ba9/attachment.sig
More information about the dojo-contributors