What is bloat?

By on December 29, 2006 12:52 am

Through the very short history of JavaScript toolkits, there has been a lot of debate about bloat, and Dojo has been no exception to said criticism.

For example, the comment by Edwin Martin on Dear JavaScript Library Developers: “I don’t use Dojo because I don’t want to add 300kB to a 20kB webpage. That’s just silly. I don’t want to let my visitors wait 10 seconds for some nice effects. Dojo has it’s use in backends, though.”

Not to pick on Edwin, but what’s silly is that despite Dojo providing systems to handle exactly these concerns, people don’t know about them or don’t understand how to use them. Dojo has a package system to define the dependencies that you need, a build system to compress Dojo into a single compacted JS file, and an in-progress linker to actually remove code that is never used or needed. There are people that use Dojo builds under 20KB, and those that have builds over 500KB, including their own custom JavaScript code.

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.

I believe that improving performance is currently the single biggest priority of almost every JavaScript/Ajax toolkit on the market. Significantly better tools such as Firebug are helping us all become more mindful of our footprint as developers, and browser vendors are also highly motivated to assist toolkit vendors with improving performance in browsers. After all, when users have 5 or 6 ajax-based applications open in different tabs, the experience is not pleasant today.

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.