Thursday, October 30th, 2008

Debunking Dojo Myths

Category: Dojo

With the rich JavaScript library ecosystem, it can be extremely difficult to make informed decisions when choosing which libraries to use for your own projects. Because no one has time to analyze each library in detail themselves, such decisions are usually made by getting a feel for what the “street” thinks and making the safe choice. Unfortunately, sometimes the word on the street doesn’t map to reality as the echo chamber arrives at a false consensus.

Dylan Schiemann recently wrote a blog entry to debunk some of the inaccuracies he’s seen crop up about Dojo, the toolkit he co-founded, addressing such points as:

  • Dojo is Undocumented
  • Dojo is Slow
  • Dojo is Bloated, Larger and More Complex than Prototype, jQuery, MooTools, YUI, etc.
  • Dojo Requires Java
  • Dojo is Verbose and is “Java for JavaScript”
  • Dojo is only Useful for Enterprise Apps and not for Small Sites or Blogs
  • Dojo is Just About Widgets
  • Interest in Dojo is Waning
  • Dojo is Ugly

It’s a great high-level update on the state of Dojo today.

Posted by Ben Galbraith at 6:00 am

3.7 rating from 67 votes


Comments feed TrackBack URI

My only experience with Dojo was in pre-1.0 days, when several of those myths were true. At the time I was shopping for a library to use in my applications, and at the time I settled on Mootools. I remember the browser hanging on load in a fairly complex app I made with it. I want to give it another try, but at this stage in the game change is hard.

Comment by tj111 — October 30, 2008

Clarification: “I remember the browser hanging on load in a fairly complex app I made with itDojo.”

Comment by tj111 — October 30, 2008

I’m not sure whether the accusations of ugliness refer to the themes or the syntax (Dylan doesn’t appear to consider that it might be meant syntactically). Either way it’s subjective, and as far as I’m concerned he’s wrong – Dojo *is* fugly :)

Comment by jtresidder — October 30, 2008

I’m using Dojo now, having only used jQuery before. I like it as much as jQuery. In fact, I’m thinking about using both of them in my next project (especially now that they are hosted on Google and are probably already cached on a large percentage of users’ browsers.)

Comment by Nosredna — October 30, 2008

I’ve made this complaint before–it’s hard to get an objective view of the libraries because usually a developer grabs one and then sticks with it. I only picked up Dojo due to a consulting job. So maybe some people know two of them reasonably well.
But probably no one knows all 5 or 6 major ones well. There’s no time–they change too quickly.

Comment by Nosredna — October 30, 2008

I’ve completed large-scale projects in Mootools, jQuery, YUI, and now, Dojo.

What you choose will depend on what kind of programmer you are and what needs you have.

For example, as a Zend Framework developer, I prefer functions to have the naming convention, which is widely adopted by Mootools (addClass, setClass, setHtml, get(), set(), etc.).

When working with designers, jQuery has been the framework of choice, since a single function does many things (css acts as a getter and a setter for one or more attributes).

Lately, I chose to “roll my own bling” with Dojo (as specified in the article) and add in Mootools-like chaining with some jQuery functionality ($(‘Ajaxian’).addEvent(…)).

Dojo has a great package system which integrates nicely into Zend Framework. This allows me to use little functionality (DOM manipulation) on one portion of the site, and have a full-stack web app on another portion, all while compressing the scripts & css down to a single file.

Just pick the right framework for the job, and go from there. There’ll never be a “one size fits all”, IMO, as they all have their strengths & weaknesses.

Comment by Liquidrums — October 30, 2008

There is a wiki that compares Dojo’s syntax with other libraries:

Comment by nrlz — October 30, 2008

@Liquidrums: rolling your own bling gets even better, I even implemented dojo.conflict() to do it for you: (linked from the article) and have been goofing around with other API’s at

For what it’s worth, .style() and .attr() are both setter/getter methods available as functions (, …)) and from NodeList (dojo.query(..).style(..).attr(..)) for chaining. Most functions behave like this in Dojo.

Dojo is my “one size fits all”, based solely on the merits outlined in the article. Small enough for progressive enhancement, flexible enough to bend to whatever form is necessary, modular design, and a full suite of development tools out of the box, all ending in a build system to automatically shrink and concat css + js files. — I am, however, clearly biased.

Comment by phiggins — October 30, 2008

@Nosredna: I think I may be qualified.

I’ve used Dojo in an extremely ambitious production app, version 0.3.1, for going on two years now. I’ve also written a book on Dojo (Practical Dojo Projects, Apress) that used version 1.1.1 IIRC. I’ve also written a a book on DWR (the only one that exists today) as well as two books on Ajax and JavaScript, both of which used various libraries (Dojo, Ext JS, Mootools, dhtmlx, Mochikit, some others). At the moment I’m writing a book on another of the major libraries (not 100% sure I’m allowed to say which one just yet). In addition, a large part of my day job over the past 2-3 years has been writing pilot apps with various libraries to make determinations about what my company should use. I’m certainly not claiming to be an expert in all of them (I won’t even claim to be an expert in any ONE of them!) but I *have* done some non-trivial work with many of them. I think I’m probably as qualified as anyone to make *some* degree of comparison between them (it’ll always just be my opinion, and you have to weigh that as you see appropriate, but it’s an opinion based on a reasonable set of experiences, perhaps more than many others).

My own personal opinion is that what Dylan wrote is *mostly* true and accurate. There clearly are some myths about Dojo out there, some of which I even held until fairly recently. Many of them were probably true at one time or another, some possibly never really were, but at least as many for sure no longer are true, and Dylan dispelled most of them very well, and most of what he said is completely valid IMO.

I do think however that some of it wasn’t quite as objective as I’d like. I said this recently during an interview for Dojo Campus (episode 6, now posted): the single biggest problem with Dojo is and has been documentation.

Now, before I go any further I want to make something perfectly clear because I think it’s important to give credit where it’s deserved: having used Dojo since 0.3.1 and all the way to the present version, I can say categorically that those guys have done a tremendous job improving things in this area, and I absolutely give them a ton of credit for it. There was a time when using Dojo was one of the most frustrating things you could do because you very much suspected there was something really cool and worth the effort there, but it just hurt your brain so much to get through that effort. Trying to figure out how to do fairly trivial things was a huge hassle. Sure, to a certain extent you have to frankly excuse it because it was beta for a long time after all, but that only goes so far. If you want people to like and use your code, it’s got to be approachable, and that, by and large, means solid documentation.

Things are A LOT better today like I said, but I think this is the primary area the Dojo team should focus on. I get the sense, as an external observer, that there is very much the engineer mentality there: get all the new hotness out there to impress the world, but don’t do the boring grunt work to get it all documented properly. And hey, I’m an engineer too, I understand fully that mentality! Still, there has to be that effort to improve matters. And in fairness I definitely know there is recognition of what I’m saying already.

My feeling is that the one area of documentation that hasn’t gotten enough attention is the basic API documentation. There was still too many times during the course of writing my book for example when I was trying to figure out the arguments a given function accepted, and it was nowhere to be found in the API docs. This to me is a huge problem because as programmers, API documentation are our primary go-to documentation when using a library. Things like The Book Of Dojo are very nice for getting started, and for figuring out some of the larger concepts, but it’s not the structure you want when you’re trying to figure out how to use a single function. The argument some people make that you can simply look at the source code isn’t valid to me because if I’m using a Java class that came with the JDK, or I’m using a function from MFC, or something from libc, do I expect that I need to look at the source code to get the gist of how a given function works (in terms of my external interface to it I mean)? Definitely not, it should be an absolute rarity that I need to do that, and I don’t expect any quality JavaScript library today to be any different. By the way, this is a failing of far too many open-source projects in general, Dojo is not unusual in this regard.

I probably didn’t make it as clear during my interview as I would have liked in retrospect, but I don’t see any real *technical* concerns with Dojo at this point. There’s nothing I point to and go “see, that’s a *technical* reason I don’t like it”. Some of the things Dylan talks about are debatable of course… Is Dojo’s code ugly? Are the widgets ugly? Is the style you tend to adopt with it something you like?… but most of the things are quantitative. Dojo’s girth is no longer a problem, as Dylan says. Widget startup times are no longer a problem in general, if you do things reasonably well. From a technical standpoint, I think Dojo is pretty solid. You can always debate how you think it fares against other alternatives, but what Dylan says about the technical characteristics and merits of Dojo all strike me as pretty fair and accurate reflections of Dojo’s reality today.

I just wish it could skip a release cycle or two in terms of new features (and Dojo is, I think nearly always, the most cutting-edge library out there in terms of new, cool features) and instead have a release or two that focused entirely on getting the documentation to be top-notch. Dylan is 100% right to say the documentation has improved greatly over time, but in one mans’ opinion, this is still Dojo’s greatest weakness, and possibly it’s *only* real weakness.

Comment by fzammetti — October 30, 2008

Ouch, I wish I’d have realized that line breaks don’t show up in posted comments… I would have at least TRIED to be more brief :) (not one of my strong suits, so I may well have failed at the attempt, but I would have tried!)

Comment by fzammetti — October 30, 2008

Thanks for the response. I usually throw in periods after paragraphs on Ajaxian. Silly, I know.
Documentation is something I’ve had trouble with in Dojo as well. Sometimes I have to google and go through 10 or 12 links before I find an answer. I like how jQuery has an example in the online docs for almost everything you can do.
The book I’m using is Dojo: The Definitive Guide. Can you tell me if any of the other books would be good 2nd books? Or would they just cover the same things?

Comment by Nosredna — October 30, 2008

I’ve yet to see a comprehensive online demo suite of Dojo features. They really need to invest some time in proper advertising. Take a look at ICEFaces or Telerix Rad Controls for the scale of what people want to see. Dojo has a few widgets that have been up forever. It doesn’t sell me at all.

Comment by ilazarte — October 31, 2008

I think every group has its own conflicting views: Developers prefer to write fancy new stuff, but not to document it. Authors are willing to write books, as long as they get paid for this, but not to contribute their knowledge to the official docs (for free). Companies prefer to write Blog posts, as long as they see a chance to advertise their commercial services, but not to work on the documentation. Users grumble about docs, but they do not see the work behind this and the need to participate actively in better docs. To be fair, I think the documentation problem comes with a lot of Open Source projects these days, not only Dojo Toolkit.

Comment by MarcusReimann — October 31, 2008

@ilazart: ? There is a lot there, but it isn’t comprehensive by any means.

Comment by phiggins — October 31, 2008

>>To be fair, I think the documentation problem comes with a lot of Open Source projects these days, not only Dojo Toolkit.
Sure, but jQuery managed. Dojo must know they have to compete with jQuery, right? And they know that jQuery has more users and more heat now. There’s a running example of just about everything you can do in jQuery. Dojo needs that. They need to figure out how to allocate resources to do it.

Comment by Nosredna — October 31, 2008

@Nosredna, jQuery is not a widget library. Compare jQuery to Prototype or MooTools, but not Dojo. Dojo should be compared with Ext-js, SmartClient, etc. BTW I just looked at the jQuery 1.2.6 internal code doc. It’s not that great (but better than Prototype’s). Dojo internal doc for the most part is very good and the code is very readable. The problem Dojo’s external doc, which is balkanized and not complete. But there are seven book to choose from:

Comment by Les — October 31, 2008

I don’t buy that. Dojo core is what I’m talking about, and I see that as in competition with jQuery.
The optional Dojo Widgets I’d compare to jQuery UI.

Comment by Nosredna — November 1, 2008

I have done google searches for “dojo table” and “dojo grid” and found nothing but crap.

I could be catagorized as an old school client server application developer (with 10+ years experience), and realy want to know: does Dojo have a great table widget?; Can table be sorted on multiple colums?; where the heck are examples of connecting a Dojo table with an open source database like MySQL?; Does the Dojo table have hooks for asyncronous updates.

I found nothing. There does not appear to be anything. If there was some Dojo table widget, would I have include their entire library. Who the heck knows!!!

I would answer YES to:

* Dojo is Undocumented
* Dojo is Just About (funky fade) Widgets
* Interest in Dojo is Waning
* Dojo is Ugly

Comment by sturdyworks — November 2, 2008

Hi guys. I’ve used jQuery, Dojo, ExtJS a fair bit, and I’d probably say that dojo is my favourite library, in terms of approach, architecture and ‘ideals’. But to be perfectly objective and unbiased, I think that
a) the documentation sucks. It has improved a lot, which bought it from completely absymmal to ‘sucks’. Up until VERY recently, the damn was OFFLINE! And before that, it was UNUSABLY slow using some sort of ‘real time’ class parser. It really was appalling.
b) sorry, but dojo is ugly :) I dont mean the code, i mean the looks. You compare Dojo grids and widgets to ExtJS, and ExtJS BLOWS IT OUT OF THE WATER. Its little things, like the ajax loader image being positioned oddly, or the sorters being positioned a bit strangely. Not only the graphics, but the way that widgets/grids etc load in ‘piece by piece’ – makes it ‘feel’ clunky. If I were ‘driving’ the development of Dojo, I would, as a matter of urgent priority, get a top qualiy graphic designer to develop a completely slick, cutting edge theme that is on par with the level of Ext (or beyond), and include it in the next release! Think Vista/mac. Think Adobe Air. Make it look *GOOD*! Not ‘techy good’, but ‘graphic designer good’. Given that dojo has such a great ‘architecture’, developing a rock solid theme for it is very little work, and VERY LARGE benefit.
c) In terms of “dojo is slow” – I’d like to go back to my initial mention of ‘how widgets load’. In ExtJS, when a widget displays, the whole section will ‘snap into place’ in at one moment (even if the actual load has taken a while), Dojo seems to load the widget part by part, which looks really bad, really clunky, and to me, gives the ‘perception’ of being slow. This has a HUGE impact on the ‘look and feel’ of dojo in my opinion, and might be something dojo might want to consider looking at, to remove this ‘myth’. Grid in particular – there’s just something about the way it moves/feels that is less responsive than ext.
It seems to me that dojo is created by techies, who forget the ‘higher level’ angles. If you want to pitch the product to high end enterprise corporate environments, Get the graphics right, get the documentation right. Don’t get defensive, just do it.

Comment by Gavin — November 2, 2008

@studyworks – its called a ‘grid’, a ‘datagrid’ to be exact. And FYI, Dojo was one of the first (open source) frameworks to implement a proper fully functional Grid into their framework. jQuery still doesnt have one in its UI.

Comment by Gavin — November 2, 2008

Gavin: I agree completely. And yes, these items are at the very top of our priority list. I will make one point with regards to b) Dojo makes it possible to make powerful apps that do look great, but the out of the box Dijit themes and widgets are not as polished as I would like (but fortunately are improving and progressing). In the apps we’ve created for our clients, or in the Dojo Toolbox or our sensei reader training app, we’re much closer to what I would consider acceptable on the UI front.

Comment by Dylan Schiemann — November 3, 2008

Leave a comment

You must be logged in to post a comment.