Also interesting

Error. Page cannot be displayed. Please contact your service provider for more details. (30)


Link of the day - Free Macbook Air

 

Interview with Dojo creator

one of the best ajax frameworks

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. Even other framework developers take their hats off to the amazing work done by the guys at dojotoolkit.org, and many of them include Dojo as a part of their own frameworks.

I had a chance to talk with Alex Russell, one of Dojo's creators, about the framework's success and future. Alex had plenty of interesting things to say, so I've divided the interview into two parts. The second part will be posted tomorrow.

Dojo Background

Q: Alex, what's the history of Dojo? How did it come about? Who was involved in it's creation?

A: Dojo was the result of some fortuitous hiring by Informatica. They had already pulled me away from a job in security to help make their web-based BI (business intelligence) product more responsive and another team "needed an Alex", so I got in touch with most of the folks I knew from my days hanging out in comp.lang.javascript and on Dan Pupius' excellent DHTMLCentral.com. It turned out that, like me, most everyone had gone and gotten "real" jobs since no one wanted to pay a bloke to sit around and make things dance on a webpage in 2003. Getting back in contact with everyone inevitably started discussions. There was a sense of doom at that time around DHTML and JavaScript. Everyone had (re)invented the same things multiple times and I started to realize that at some point people reach a "personal effort radius". Even for people as persistent as DHTML hackers, there's a limit to how far one person can push something and in those day we only really shared code snippets and techniques. There weren't any "canonical" libraries despite many attempts (including my own) at it. The market didn't see a need.

The upshot of these discussions was a new mailing list which has subsequently become the Dojo contributors list. The original folks early on the list were Aaron Boodman, Dylan Schiemann, Tom Trenka, Simon Willison, Joyce Park, Mark Anderson, and Leonard Lin.

Fast forward to early 2004 and Dylan Schiemann and David Schontzler were also at Informatica and just as David was heading back to school we started on a new project that looked like it would need good SVG support. We needed a library that would be portable between environments, and Dojo was born. Retrofitting netWindows just wouldn't work. It was far too HTML specific. We tried to make a case for writing Dojo while working on this project and got some initial support, but in the end it was the folks at JotSpot and Renkoo that really helped push the project forward in the early days through their generous support.

By the time we had started on the new project at Informatica, we had gotten some momentum on the mailing list to try to combine all of the tools everyone had laying around. We set about to build a Standard Library for JavaScript. The original intent (and something we still hope to do today) was to get the best code and approaches from the community and boil them down into a single package.

We got all the IP donation stuff sorted out and it was off to the races.


Q: And the name "Dojo?"

A: The name "Dojo" came about because I had received a Cease and Desist from Microsoft when they noticed that my one-man DHTML project -- netWindows -- had the word "windows" in it. Of course, you can't appropriate a word out of the language, no matter how much money you throw at it, but Microsoft seems to think they can. When we went to name the project it was decided that we should pick something less likely to get us sued, so Leonard Lin proposed "Dojo," and compared to all the other dreck that was being suggested, it won easily. Naming things well is hard!

Obviously the recent past has lots to do with Ajax, Jot, IBM, Sun, the general dynamic-languages renaissance, but I've blabbered enough on this, and everyone always loves the creation myth more than the hard work parts anyway. ;-)


Q: What exactly was netWindows?

A: It was my first attempt at a DHTML library. It included things like a widget system, a theme system, a signals-and-slots event system, some useful widgets and a pre-XMLHTTP IO infrastructure using a request queue built on top of Iframes. There was even a primordial build and compression system. Some of the stuff in netWindows, like a generic focus manager, still haven't made their way into Dojo yet. Luckily we all got a chance to "reboot" with Dojo and take only the best parts out of netWindows, Burstlib, f(m), and some other codebases that have been donated along the way.

Dojo Strengths and Weaknesses

Q: What would you say are the strengths and weaknesses of Dojo?

A: We've got amazing infrastructure to support for folks who know and appreciate JavaScript as a language and know what they want out of a toolkit. Dojo is a set of layered libraries and a lot of folks love the ability to pick just the bits the like and ignore the rest, and while that's a strength for the folks who need that much power, it's a liability for everyone else.

In terms of weaknesses, the obvious answer is "documentation". We have a communication problem around trying to get the word out about how Dojo is layered and how to use it in real-world scenarios. We're working on those things, but some of it is inherent in trying to build something so broad within the constraints that the web imposes.


Q: Dojo has been criticized as being too heavy. How do you respond to that?

A: I'd respond "what are you trying to get done?"

In a lot of cases people assume that Dojo is some kind of monolithic thing. They download a release and go "OMG! It's huge! all these files, where do you start?" and I sympathize with that. In the past we've discussed breaking things up, but then you have the problem that a lot of other folks have today which is that you dump the problem of assembling the right versions of all these different things that work together and load in the right order onto the end developer.

The package and builds systems lets us avoid most of that, but we still ship the "src/" directory so that if you want some part of the library that's not part of a build, you can just say dojo.require("dojo.someModule.*"); and you can trust that it's going to work, that all of its dependencies will get loaded in the right order, and that you can make it faster later if you need to by dropping unnecesarry code.

We know of some people who use just the package system (around 20K, built) and people who do entire application UI's as Dojo widgets, and the system scales to both extremes. We ship the various profiles to give people people a head-start, but the system is flexible to the core. So the answer to the question is: Dojo is as heavy as your application requires and your interest in "right sizing" it lasts.


Q: What is your favorite feature of Dojo?

A: Hard to pick, but since I have to pick I'll say the build/package system. I hate Ant and I'm no lover of Java, but they've allowed us to solve a very hard deployment problem in a way that doesn't require anyone to change their code. Just make a build, point your app at the new "dojo.js", and your app loads that much faster. I love things that let you start developing fast up front and put the work of "making things fast" a deployment issue, where it belongs.


Q: There are client-side, server-side and various other classifications of Ajax frameworks. How would you characterize Dojo?

A: Pure JavaScript. We try to implement generic protocols for talking to servers such that we don't have a dependence on any particular server-side language or environment. As a result we've grown things like great JSON-RPC support. Of course, we don't have a strong identification with a particular group of developers the way Prototype/Scriptaculous or Atlas do, but that's fine by us. In our experience most good developers write in multiple languages on the server side, so why shouldn't their favorite JavaScript tools be portable? We've always had a mantra that I borrowed from Joe Kraus and modified a bit: "optimized for adoption, not control."


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.


Q: Why do you say that Javascript is a "more powerful" language than Java?

A: Oh boy, I'm gonna get in trouble with this one. ;-)

Before I get into it, let me say that I write a lot of Java myself and don't view Java and JavaScript as being in opposition, and even less so with the introduction of Rhino into Java 6 (Mustang). Pretty soon most Java developers will get the language advantages of JavaScript with the library support of Java. The best of both worlds.

As a language, JavaScript is still horribly misunderstood. All real power in JavaScript comes from understanding closures, the "everything is always mutable" property, and the prototype chain. These are foreign concepts to Java developers who don't have FP or scripting backgrounds.

Even those that do, don't often recognize JavaScript as a language of that type. It's quite a good chameleon in that whatever you think it is, it's probably also that (or can be made to look like it). Making matters worse, there are a lot of idioms that the JavaScript community has cobbled togeather over the years to build classes that have some of the same properties as what's found in class-based OO, but fundamentally JavaScript is a different beast.

JavaScript is a functional language trapped in C-style syntax. It allows you to compose logic in ways that languages like Java generally require bytecode or precompiler antics to achieve. There has been some work in the Java world to introduce more powerful, more generic and more composable building blocks (e.g., jakarta commons-functor, but even that seems to have fallen into disrepair). In the end these efforts are always working against the grain of the language and even if they weren't, they face a similar comprehension gap among Java developers.

The JavaScript style of data hiding via closures is the flip-side of class-based OO: instead of having instantiable data structures that carry around behaviors, closures are behaviors that carry around their data with them. Thanks to the prototype chain and some magic in the "new" keyword, they can be made to look like class-based OO from a distance, but that illusion breaks down pretty quickly. Most Java programmers just assume that JavaScript is somehow "broken", when in fact it's just providing more abstract primitives for getting at the same end goals. Consider this highly contrived code:

  function getThud(){
    return this["thud"];
  }

  function ClassFoo(){
    this.thud = "xyzzy!";
  }

  ClassFoo.prototype.getThud = getThud;

  function ClassBar(thudValue){
    this.thud = thudValue||"default thud";
    // constructor assignment
    this.getThud = getThud;
  }

  fooInstance = new ClassFoo();
  alert(fooInstance.getThud()); // will be "xyzzy!"
  barInstance = new ClassBar();
  alert(barInstance.getThud()); // will be "default thud"

  // prototype extension affects all existing objects
  // of a class as well as new ones
  ClassBar.prototype.getThud = function(){
    return "prefix plus "+this.thud;
  }

  barInstance2 = new ClassBar();
  alert(bar2Instance.getThud()); // will be "default thud" (!!)
  barInstance3 = new ClassBar();
  delete barInstance3["getThud"];
  alert(barInstance3.getThud()); // will be "prefix plus default thud"

The implementation of logic can be promiscuous but object and closure scope can be used to make things immutable. The Ruby guys call this "open classes". I'm sure this code example will make strong-OO folks shudder in horror. OMGWTFBBQ! What if the implementation changes? How does anyone know that getThud is a member of ClassFoo? What about API versioning? Closures give us answers for all those things too but I'll leave that for another time.

The upshot of closures, the primality of the function object, and the prototype chain is that it's possible to better express your intent as a programmer in less space than Java and without resorting to syntax or contored class hierarchies. The language is just more supple. It bends more easily to your will.

There was a fascinating paper by Lutz Prechelt in 2000 entitled "An emperical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl". Among a representative sample of programmers, he found that scripting languages produced better performing programs that used less resources and required roughly half as much code as their Java equivalents.

Scripters lost out big-time in I/O (expected) and C and C++ developers could turn out code that beat all, but not with as much reliability as the scripters. The scripters on the other hand beat everyone for productivity despite roughly static LOC/hour productivity between the programmer populations. Takeaway?: if you're a decent programmer but want to look freaking brilliant, use a scripting language in a Java shop.

The paper wasn't a "do the same thigns the same way" kind of benchmark, it was a sampling of how programmers think about the problems they're presented with given the facilities of the various languages. In the 50's there was this paper called "The Magical Number Seven, Plus or Minus Two" that outlined the limits on human capacity for keeping things "on the stack" when solving problems. The limits are just as real today, and the mildly functional programming style that most scripting languages expose adds new tools for managing and encapsulating complexity to the programmer's toolbox. OO clearly isn't going away, but single-paradigm languages seem to be at a statistical disadvantage. I think we're seeing a realization that 20 years into the experiment, strict OO design is not the be-all and end-all of complexity management. Functional programming probably isn't either.

The hybrids (Python, Ruby, JavaScript, etc.) seem to have real legs these days. Luckily for the Java world, Sun is finally adding good scripting interfaces to the language. They're 5 or 6 years late to the party, but it's a big improvement for the lot of Java devs none the less.

JavaScript is poised to become a productivity shot-in-the arm for Java.

I can't wait to see how it plays out. Will Sun have the foresight and political will embrace the future? There were signs of it at JavaOne this year, but it was fleeting. From what I can see, the church still has the state cowed and functionally imobilized.

Shop Bigger Bras