But that begs the question, what is bloat? jQuery has recently been touted as lean and not-bloated, and yet, if you start to add in a number of jQuery plug-ins and your own code, does it not become bloated? By this definition, modularity is one way to not be bloated. Dojo out of the box provides a lot of functionality (bloat perhaps?), but does so in a modular manner to help you not deploy bloated code in a production environment.
Prototype and script.aculo.us have been mentioned as small and lean because of several reasons, one of which is their lightweight syntax including the $() and $$() functions. So by that definition, concise syntax implies less bloat. Dojo uses the syntax dojo.byId() instead of $(). I don’t believe this is the definition of bloat, but rather personal preference.
Assuming we can rule out syntax, and lines of code (because modularity in theory solves that issue), this leaves us with the only issue that I believe should really matter to end users, and that is actual end user performance: memory consumption, CPU usage, and page load time. Profiling your performance and looking for bottlenecks and inefficiencies is the only way to reduce bloat, in toolkits and in your own code.
For example, Dojo provides a mechanism by which your markup can be inspected or parsed for widget markup on page load. In theory this is a great idea, but in practice it can be a significant performance bottleneck if your source document contains a large number of nodes.
Another common performance bottleneck is making too many requests to your server. Dojo by default will use XMLHttpRequests to incrementally get any dependencies that are not included in your dojo.js source. This is great at development time, but can lead to really slow performance in production.
Dojo will be working over the coming months to improve performance, which is something we have been doing with each release of Dojo. But improving toolkit performance is not enough… we also need to share best practices on how to get the most out of our browsers, and to ask for more from browser vendors (they’re already listening). We will be writing a series of posts on performance tuning and testing, and we look forward to reading your comments and trackbacks, and learning from your performance tips. We as a community need to fix this issue before Ajax suffers the same fate as DHTML. After all, no one likes to be bloated.
Next time: the tools of the trade and how to use them effectively.