[dojo-contributors] bloat

Bill Keese bill at dojotoolkit.org
Wed Apr 5 01:28:38 EDT 2006


Like everyone else I'm concerned with bloat, but I tend to think that we 
should fight bloat the old fashioned way, by writing streamlined code 
and by refactoring repeated code into library functions.  As an example, 
my recent floating pane rewrite reduced the file to 50% of it's original 
size, eliminating 5 pages of code.  I'm sure we can do the same for a 
lot of other widgets and other code.

As for deleting apparently unused functions from the code - I'm in favor 
of it.  It runs the risk of inconveniencing some people but I think the 
pros outweigh the cons.  Whatever we do will be bad for someone, so 
let's just pick the route that is best for most people.  Keep in mind 
that developers leave old APIs in the code because they are afraid to 
remove them, not because they think they should be there.

One option is to move all the deprecated functions to a deprecated.js 
file.  It would mixin to existing classes.

About streamlining builds by reducing dependencies between modules, 
especially eliminating dependencies on rarely used modules... there's 
some value to that, but I'm not too optimistic about it.  For instance, 
we recently split dojo.lang into multiple files, but I suspect that most 
builds including all those files, thus making the split useless.  It 
seems like wishful thinking to me.

 > 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.

Not sure what you are getting at here.  The "stable" modules are the 
ones with the *most* bloat, because they have been around the longest.

Bill



Alex Russell wrote:
> 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
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors



More information about the dojo-contributors mailing list