What is bloat?

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.

When I first started using Dojo, I believed in its packaging sytem and the features that it offered. However, when I implemented my website using Dojo for the first time, I couldn’t believe how much code, in byte size, it added to my pages. I looking into it, and found that Dojo was loading libraries and code that I wasn’t using, but was included as part of the dependiences for certain widgets and etc. So I’m looking forward to the linker.

So, with that said, I just want to give you guys props for Dojo, thanks and keep up with the great work. I’m looking forward to the linker. I think the linker will, without a doubt, make Dojo the best toolkit out there.

Awesome points Dylan! There are too many people who should know better who don’t seem to have TRULY internalized that with the aggressive caching of most browsers today as well as ubiquitous broadband, size of download is rarely the real issue. Plus, people often point to a single 500K JS download as “bloat”… but a page with 20 downloads of 25K each doesn’t faze them!!! Which isn’t to say that we Dojos don’t have a lot more work to do explaining our ideas clearly and understandably to app builders… but pieces like this will really help.

To answer that question, we take Opera support seriously, and the issues I know of with Opera are limited to some of the widgets, and a few of the less common APIs such as our XSLT support. Certainly if you find any bugs or issues with Opera and Dojo, please file a ticket and we’ll get them fixed asap.

I am an admirer of dojo and appreciate the work of its development team. I have a question on ‘build’. When you speak of a build it sounds like something for the ‘Unix’ guys, what do you have for the ‘windows’ guys?

Also there must be a flag of some sort that just looks at the ‘dojo elements’ on the page and automaticlaly removes unnecessary script references(or include only the relevant refrences) from the page thus reducing the ‘bloat’. Is it a silly question suggestion?