Dojo Goodness, Part 1

by Matthew Russell

Since I'll suddenly have copious free time on my hands once I turn in my final book manuscript this weekend, I decided that it might be helpful to start a short column on some of the fundamental Dojo building blocks. Although I certainly won't be able to give this column the same "definitive guide" coverage that you'll get in the book, my hope is to show you some tools that will increase your Dojo awareness and get you excited about some of the things that Dojo can do for you.


Eric Bresie
2008-03-11 19:42:26
For your Dojo articles, having an example of what you are talking about either via a link to a page with the example code or embedded within the actual article would be nice.
2008-05-28 13:34:40
When you said, "...let’s get rid of the blanket statement that Dojo is bloated." You did not get rid of the very valid statement that Dojo (and most if not all 3rd party JavaScript libraries) is bloated. Bloat is not just an issue of bytes, which can be tokenized and compressed, but an issue of unnecessary code statements. This comes from two sources: code that is never used in a particular Web application but part of the downloaded library, and code that is overkill for the task.

Dojo does a better than average job of modularization allowing the developer to load only used modules, but there is still code that is not going to be used, and this will have an impact on performance; albeit, small.

Developers of the libraries are without doubt very talented, but the code is sometimes too slick for the room. Often users replace simple JavaScript statements with overly generalized methods that contain extra statements to cover a wide variety of possibilities (an more rare special instance use). And, the way the objects are constructed (overly abstract and complex at times) a series of nested method calls is used where simpler code would do.

Using six statements to do what can be done in two, or using three method calls when the task can reasonably (considering maintenance) be done with one call is the definition of bloated.

The syntactic sugar provided lends the appearance of simplicity, but when one uses a debugger and steps through the code the bloat is becomes apparent.

Robert Stackhoukse
2008-08-07 05:57:48
It would be helpful to link to the next article from the previous one (i.e. link to part 2 from part 1).