Wednesday, August 16th, 2006

An Interview with Dojo Creator Alex Russell, Part I

Category: Dojo, Framework, Interview

A case can be made that Dojo is the single most influential framework in the Ajax universe. Any time I talk with Ajax developers about frameworks, the discussion always turns to Dojo. I had a chance to talk with Alex Russell, one of Dojo’s creators, about the framework’s success and future. Part I of the interview (he had a lot to say) covers the origins and motivations for Dojo, it’s strengths and weaknesses, it’s competitors, and the relative merits of Javascript and Java.

Q: What do you see as being the biggest competitor to Dojo?

A: Short term, the closed-source frameworks like Backbase and Bindows probably have the same breadth and depth as Dojo. Longer term, I think that we’re in for an interesting time in figuring out if they’re all anachronisms in the face $serverSideLanguage -> JavaScript “compilers”. GWT doesn’t make any sense to me since it’s a less-powerful language being transformed into a more powerful one, but Python to JS and Ruby to JS look like real competition.

You can read the rest here. Part II is here.

Posted by Dietrich Kappe at 11:51 am

3.7 rating from 75 votes


Comments feed TrackBack URI

Possibly the most thought about but prototype surely is the one most of us actually use. Dojo ends up being lovely to think about but quite heavy to use. Great for some apps but not all.

Comment by Paul Watson — August 16, 2006

>>prototype surely is the one most of us actually use. Dojo ends up being lovely to think about but quite heavy to use

Hmm, that’s the reson I’ve been looking at jquery rather than prototype!

I find dojo freezes firefox completely for a few seconds onload. At tleast the dojo example pages do. Very annoying.

Comment by ziggy — August 16, 2006

Ziggy: which example pages? are they using a build or are they from source? Builds should be pretty snappy. See the test pages at:

Comment by Alex Russell — August 16, 2006

I tried the examples in that link u provided with IE 6 with ActiveX disabled (company policy). They all failed giving me “Error: XMLHTTP not available”. How come this is required for menues, layout examples etc?

Comment by José Jeria — August 17, 2006

Jose: Those builds use Ajax to pull in code for the widgets via the package system. It’s possible to make a Dojo build that won’t request those files at runtime, but these pages do. Thankfully IE 7 will give us XHR w/o ActiveX, as Firefox, Safari, and Opera do today.

Comment by Alex Russell — August 17, 2006

But surely there are dojo tooltips, menues, and simple layouts that don’t require ActiveX, right?

Comment by José Jeria — August 17, 2006

[…] Ajaxian is interviewing Dojo creator Alex Russell and I was pleased to read the comment about closure: […]

Pingback by ScriptTeaser » Blog Archive » Dojo Creator interviewed — August 17, 2006

Personally I prefer not to use prototype.js as it becomes a real problem when you need to do introspection. Because prototype.js adds functionality to the Object class, all classes are affected by inheriting extra properties such as “extend”. which becomes a pain and you have to treat these properties as predefined reserved words and ignore them. Sometime when I want to use prototype.js features, I have a rewrittened version without the properties added to Object class.

Comment by Unknown — August 19, 2006

I dislike Dojo the same way I dislike struts(the J2EE MVC framework). Its great to have a powerful and robust kitchen sink framework, but there is no consistency in quality when look at the different modules or even different parts of the same modules. Some feature are of very high quality while other are sloppy. I like the core system, but the elegance is not propogated outwards due to low quality contributions.

Comment by Anonymous — August 19, 2006

We have tried out Dojo and YUI for an application that we are developing. Dojo has made some great contributions in terms of pushing the envelope of what a JavaScript library can do and should do. However in the end, we have not used Dojo, because it is heavy. I believe there is also some fundamental issues with their library loading system. The comment Paul made about Firefox locking up is not just some weird compatibility problem. Correct me if I am wrong, I believe that Dojo is reliant on synchronous (not async) XHR (or dyna-script tags) calls to load its libraries in the midst of execution. Synchronous means the browser must lock up until the library is loaded. While dynamic library loading is indeed cool, this is a major issue.
But, I still tip my hat to Alex. Also their aspect-oriented event handling is brilliant.

Comment by Kris Zyp — August 19, 2006

I love how the first comment about an interview w/ Alex of Dojo is about prototype ;) It’s like writing about Safari on an Firefox post. It’s inspiring how Dojo’s garnered the support of so many big software players. And Alex always seems to be on the cutting edge of thought and library support for the latest and greatest techniques. And it’s purely based on community! No gigantic money-laden company is directing the development. Also quite interesting, given that we seem to wrangle endlessly about which framework is the best, is this part where Alex mentions ruby->js and python->js approaches. Sometimes I feel like agnostic code (Javascript + some server language, but they don’t care about one another) is constraining, and sometimes liberating. But it may ultimately be inefficient!

Comment by Lindsey Simon — August 19, 2006

Kris: The synchronous loading of modules is only for those things that aren’t baked into profiles. You can also pull things in with tags directly. This is why the build and package system are so powerful, they let you start developing without having to know the dependency order and then you just make a build when you want it to be fast in a deployment scenario. That you get to choose is perhaps the new variable that Dojo introduces which other toolkits don’t provide. I can understand how it might not be obvious.


Comment by Alex Russell — August 20, 2006


One of the things we see people doing in large-profile situations is to actually defer calling dojo.require() until the widget is needed, assuming that it won’t be used when the app initially loads. This way, you can build a common profile and then as you get to different “areas” of a single-page application, you load only what you need in addition for that section. Sure, it’ll be synchronous at that point, but it’s only pulling in what wasn’t already loaded and it’s in reaction to user action which buys you a lot more in terms of expected latency.

Because you don’t need to require() everything up front, you can use Dojo’s built-in facilities to implement whatever optimization strategy is best for your site. It requires more work to figure that out, but at least you won’t have the additional work of trying to figure out how to load the code and manage dependencies.


Comment by Alex Russell — August 21, 2006

>>Ziggy: which example pages? are they using a build or are they from source? Builds should be pretty snappy.

Sorry, for the delay, Alex.

Just tried again. Go to your homepage, freezes the entire browser for a couple seconds. Stutters for a moment, then freezes again, then the page is loaded finally. Doesn’t matter if I’m on that tab or not. FF1.506, XP. Does it every time unless I just loaded it. Does it again briefly when clicking to view a first demo.

Sorry, only website I experience it on anywhere, and been the same since I first visited ages ago.

Comment by ziggy — August 24, 2006

Alex, I just tried the new filter/sort table example and it SERIOUSLY locked up the browser to the point where it even disappeared from my task bar and went all white and only came back after 5-10 seconds.

Hope it helps.

Comment by ziggy — August 24, 2006

Leave a comment

You must be logged in to post a comment.