Dojo: The Definitive Guide

Foreword

Truth be told, it was DHTML that got me kicked out of college.

I still vividly recall the 3 A.M. moments when endless trolling of MSDN documentation and W3C specifications and hundreds of comp.lang.javascript posts all coalesced into dozens of "what if . . . " moments. Like hot brands on the hide of my brain, each of these tiny discoveries would not let their mark off of me until I had exhausted all inroads into making the browser do what I wanted it to. Back then, a small community of folks were all doing the same, feverishly one-upping each other and posting to the DHTMLCentral forums with each new component, technique, or hack to make things work on Netscape. Nothing about 7 A.M. Latin conjugations or endless lectures on Java? held much appeal by comparison to discovering the true beauty of closures, or finally, completely understanding prototypal inheritance. Even my Christmas holidays were engulfed in JavaScript learning and hacking. I'm sure my girlfriend and my parents worried for me greatly, but they never said anything. From the ashes of my truncated academic career came an understanding of open source (http://opensource.org), lasting friendships, and, eventually, Dojo.

Over time, the job of the DHTML hacker has changed. We know most of the tricks that we can expect a browser to do, and where there is overlap between browsers, we've probably already exploited it . . . just look at the depth and diversity of modules in Dijit and DojoX. The work of a DHTML/Ajax developer now is to press the available technology into the service of users and developers in ways that are better for end users and developers alike. The story of Dojo is the story of that transition. A beautiful architecture that fails to deliver better things in the lives of users is a failure. Likewise, beautiful graphics and interfaces that aren't maintainable, can't be coherently understood by developers, and that make designer/developer collaboration harder aren't going to get us where we want to be. All of us involved with Dojo have matured along with the Web, and with the release of Dojo 1.0 and this book, it's safe to say that Dojo has fully arrived. The roadmap documents we started so long ago now have all of the boxes checked, sites that serve billions of page views a month lean on Dojo for their entire user experience, and large teams of designers and developers work together to create better experiences on top of the toolkit.

These kinds of accomplishments aren't the work of one person, or even a small team. The number of people who have contributed to Dojo's evolution, believed in the project, and worked together to deliver a better Web are too numerous to mention. We copied what we thought were the best bits of the structures of other projects, and the result has been a level playing field and rules that are fair to users, contributors, and sponsors alike. Dojo is proof that open source isn't just a handy distribution model for closed systems, but that collaborative, open projects can thrive when they adopt policies that let users trust a project and when those inside the project finds ways to trust each other. For all of the technical achievements embodied in the toolkit, I'm most proud that we've done it in the open, with anyone who will join us, and done it honestly. We set out to build a project that values all kinds of contributions, not just code. A project that would help change the tone of open source development to encourage collegial, civil discourse. A project dedicated to building with the community and not to treat users as "them." "They" are "us" and this book makes plain the open philosophy under which the toolkit was built, and by which we encourage all those reading it to help us evolve it for the future.

By the time I met Matthew Russell face-to-face, this book was nearly "in the can." Open source is funny like that—you can work for years with someone, yet the pieces picked up over mailing lists and IRC don't fall into place until you're talking about the mundane and thrilling over a good local ale (or, in a pinch, Guinness). It wasn't until Matthew and I were comparing notes in an old, small, quiet pub in San Francisco's North Beach district that it clicked: his technical depth, curiosity, and ability to meet you on your level are the hallmarks of a great teacher. As I reviewed the draft chapters in turn, I found myself constantly deleting what I'd just written by way of critique as Matthew laid out the concepts in just the right order. Matthew's illuminations make Dojo approachable, friendly, and productive. The constant delight of discovery that glows so brightly when you talk to Matthew in person are a true gift to this volume.

It has been like this for me for nearly four years now as I've had the chance to put faces to the IRC handles and forum posts. In open source, each person enters your world as a technical problem to be solved, a bug to be fixed, or a feature to be considered. Only later is the full measure of the people you're working with made plain, and it's nearly always a breathtaking revelation. The kindness, selfless effort, and talent that are freely given are humbling particularly in light of the personal sacrifices that each person makes to be a part of the project. Matthew's book is a credit to the amazing team I've had the honor to work with.

I can't say that I recommend dropping out of college to work on things that no one will pay you for, but if that fire starts in your brain, don't ignore it. If it leads you to people only half as wonderful as those I've met and now count among my friends, it will be worth every sleepless night.

—Alex Russell

Cofounder, Dojo Toolkit, and Dojo Foundation President