[dojo-contributors] bloat

Alex Russell alex at dojotoolkit.org
Wed Apr 5 00:40:21 EDT 2006


Hey everyone,

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:

	1.) be the "standard library" for JavaScript
	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 
stability:

	* 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 
(stalled?)
	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.

Regards

-- 
Alex Russell
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
Type: application/pgp-signature
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 mailing list