Alex Russell, the founder of the Dojo Toolkit, is quoted in an October 2006 eWeek.com article as saying Dojo "is like crack for Web developers... It's like crack; once you start using it on a daily basis, you don't go back." A project's founder can be expected to hype his creation, but it's another thing when key contributors to the project speak about it glowingly, even with awe -- and at the same time be willing to point out the project's limitations, to-dos, headaches, and challenges.
Some of Dojo's key contributors from IBM® got together recently to talk about where Dojo has been, where it is now, and where it's going. They also gave insights into the details of their specific project areas and discussed the challenges of working on an open source project where face-to-face meetings are rare. You can read what they said below.
Warning: their enthusiasm is addictive!
Dojo is an open source DHTML toolkit that was started in 2004 and has since become very widely used. The overarching goal of the project is simple: make a toolkit that is so robust that it will spark "mass adoption of dynamic Web application development." Dojo is an ambitious project. If you visit the project's Web site, you'll find page after page describing Dojo features that could indeed become habit-forming. For example, the introduction to the Dojo Widget Library, known as Dijit, says:
| Everything in Dijit is designed to be globally accessible -- to accommodate users with different languages and cultures as well as those with different abilities. Language translations, bi-directional text, and cultural representation of things like numbers and dates are all encapsulated within the widgets. Server interactions are done in a way that makes no assumptions about local conventions. All widgets are keyboard accessible and using the standard Dijit theme, usable in high-contrast mode as well as by screen readers. These features are baked in so that, as much as possible, all users are treated equally. |
The toolkit's Web site says that, as of April 2007, over 300,000 downloads had been made of pre-release versions 0.4x. In November 2007 alone, about 40,000 downloads were made of the 1.0.0 and 1.0.1 versions of the toolkit, which had just been released that month. (These download numbers for 1.0.x are extrapolated from download statistics published on the site.)
The Dojo project is well-funded, which assists in achieving its ambitious goals. The toolkit is one of three projects sponsored by the Dojo Foundation, which in turn is supported by IBM, BEA, Sun™, AOL, and others. If the funding continues, an ever-evolving Dojo will be around for quite some time.
Becky Gibson is a Senior Technical Staff Member at IBM's Westford, Massachusetts lab and a member of the IBM Emerging Technologies group. She started working on the toolkit in May 2006, and has contributed to toolkit releases 0.4, 0.9, 1.0, 1.0.1. At IBM, Becky is a Web Accessibility Architect. Her contributions to Dojo have focused on accessibility.
Jared Jurkiewicz is a Software Engineer at IBM's Research Triangle Park, North Carolina lab. In 2006, he started using the toolkit while working on the IBM WebSphere Application Server Web 2.0 Feature Pack, and in early 2007 began contributing to Dojo. He has worked on releases 0.4, 0.9, and 1.0.
Adam Peller is a Software Engineer at IBM and works at his home in a suburb of Boston. He started working on the toolkit in April 2006, and has worked on all releases since 0.3. He is a member of the IBM Emerging Technologies group and is currently the interim project lead for the dojoX project. He was part of the team that led the initial evaluation of Dojo and other Ajax frameworks for IBM.
WebSphere Developer Technical Journal (WDTJ): Jared, What have you been doing for the Dojo Toolkit project?
Jared Jurkiewicz: I've primarily worked on the dojo.data sections of the Dojo Toolkit, trying to drive the API to a usable point. We completed the main points of the API for 1.0, but there is, of course, still more work to be done. I've also done presentations at conventions such as AjaxWorld on the topic. Currently, I'm the primary owner of the dojo.data module of Dojo. Other than that, I also work on the dojox.wire module, and have done various bug fixes.
WDTJ: Is it fair to assume that most developers will be porting from Dojo 0.4x directly to 1.0?
Jared: Hopefully! In reality, I expect some will, some won't. 1.0 is significantly different from 0.4.X in certain areas. Users who had custom widgets will find the port to be a fair amount of work. Users who just used Dojo widgets will probably find the port relatively simple. It all depends on what the user's application does, and if it needs to be changed or not. Even on the mailing lists and forums for Dojo, a lot of 0.4.X questions come up.
WDTJ: After porting to Dojo 1.0, what benefits will Dojo 0.4 developers see in their new 1.0-based apps? And what about 0.9 to 1.0? What are the major advances there?
Jared: 1.0 is significantly faster. Page parse and render time were substantially improved. Instead of having four ways to declare widgets in markup, there's now just one. A lot of "magic" was also removed that really didn't help, because you ultimately had to know what it was doing anyway. An example is dojo.io.bind: In 0.4.X, it was supposed to have masked out the underlying I/O mechanism (xhr, script, and so on), but it really didn't. Each required special parameters anyway, so it just makes it cleaner to have them as separate APIs and easier to understand. Plus, 1.0 has had a lot of work put in for accessibility of the widgets, as well as internationalization and even BiDi support. While that work isn't 100% complete yet, it is much better than 0.4.X, not to mention any other JavaScript™ toolkit out there.
WDTJ: Jared, earlier you said that dojo.data has stagnated. Data management is critical to any programming language. Why the slowdown? What components were getting more attention and why?
Jared: Actually, the dojo.data stagnation occurred in the past and is no longer the case. In 0.4.X, I suspect the dojo.data work stagnated for several reasons: 1) It's hard, quite frankly, to develop an API that is flexible enough to handle multiple service types, handle the async behavior of browser I/O, and be easy to use. 2) Other work started taking priority. Everyone in the community has a day job outside of Dojo, really, and as with most companies, workload increases as it gets later in the year and products ship and projects complete. So, people had to ease back on Dojo contributions as they were wrapping up projects for their employers. 3) It's not as "fun" as other modules in Dojo. Widgets are fun to write; you get instant gratification. Data access APIs don't provide that level of instant feedback. In other words, it's infrastructure. So, for many Web developers, that's just not the most enjoyable aspect of Web programming to work on. Probably not the most politically correct answer, but it's an honest one. Thankfully, that is behind us! As of Dojo 0.9 and 1.0, the dojo.data work is moving forward reasonably well and we're seeing more people contribute to it as adoption of 1.0 increases. I look forward to seeing what contributions from the community emerge over the next year.
WDTJ: What do you expect to improve on in dojo.data, as of 1.0?
Jared: We have other APIs we would like to flesh out if there is time, such as a Schema API that, if stores declare they implement, provides a way to get information about the data structure (attributes and types) they contain. Other than that, more unit tests, more stores, and so on, would all be good. It's all a matter of finding the time to work on it.
WDTJ: In a recent posting on dojotoolkit.org you wrote "The Dojo Toolkit lives off the good work of its contributors and we're always hoping for more good contributors." Out of curiosity, how many folks have contributed to dojo.data, even just fixes?
Jared: In the beginning, not as many as I had hoped. Fortunately, that has been changing. Brian Skinner was a major contributor for a very long time, but he has had to pull back recently to work on other things. His work has been vastly appreciated. As for lately, I've had two others contribute stores that have made it in. And even more recently, some people posted two new stores as patches, but they are unfortunately incomplete and lack unit tests, so the code can't go in the toolkit yet. With a bit more work, they will hopefully make it in. Another contributor-submitted patch didn't include a Contributors License Agreement (CLA), so that certainly can't go in. In addition to individual contributions, we have had a recent company contribution that is now in the queue to be reviewed for inclusion, a data store written by the developers at SnapLogic. Its intent is to improve Dojo integration with their data services. The largest area I would like to see more contribution, though, is documentation. That has historically been, and still is, the hardest area to get contributions. It's not surprising, though, as developers by nature tend to hate writing documentation. I'm guilty of that too, so it's an area I need to improve on as well. For anyone who wants to contribute to Dojo, dojo.data or not, I highly encourage you to do so! Please fill out a CLA and file it with the community then join in.
WDTJ: Adam, What have you been doing for the Dojo Toolkit project?
Adam Peller: As one of the initial IBM committers for the project, I've been acting as one of the liaisons between IBM and the Dojo community, bringing IBM requirements to the Dojo community and trying to help convey information about Dojo back to IBM. I've had a lot of help on this since from people like Chris Mitchell, Doug Hays, and Jared. Since I started, my focus has been on building an internationalization framework for Dojo -- something which was really important to IBM, and something I felt no other JavaScript framework had really tried to solve. I took this on because I've seen how poor the i18n support has been in Ajax/DHTML, not because I consider myself to be an expert in the subject. I've really been a proxy for IBM's i18n experts in that regard. I've also been involved in many of the "core" modules and tools issues, and recently have gotten more involved in the Dijit project, so I find myself touching lots of code, but it's a big project and I still find that there are many parts I do not know well. I've also gotten involved in build and project management issues from time to time. Pretty much whatever it takes to move things along. It's been a real privilege being able to "play" in open source these past few years, and I'm excited to see how much people are using Dojo, especially within IBM.
Everything Jared says about 1.0 is on the mark. Overall, I think it was about learning from the mistakes we made in 0.4 and prior releases. We settled on one way of doing things when there may initially have been three, we consolidated APIs and tried to use consistent styles with less "magic," and we didn't do things we didn't have to, like error checking, or wrapping APIs that already existed (for example, dojo.dom). Sometimes it meant dropping a feature because it was just too expensive, or because it wasn't important to enough users to justify the overhead at run time or to the codebase. Reducing the code had many benefits, including performance (code size over the wire is where it really counts with script) but also in reducing the tangled dependencies we used to have.
WDTJ: In a recent posting to the Dojo Core forum, the question was asked, paraphrasing here: "why is this line used in dojo.js.uncompressed.js: var d = dojo;". Your answer was "Just saves three bytes each time we need to say 'dojo' in the given code block." Do Dojo core developers have a style guideline that they follow? Is the tradeoff between performance and readablility discussed among the developers?
Adam: There is a Dojo Style Guide, but it's mostly about the typographical stuff (white space and such), some naming and structure, and so on. It doesn't go as far as some people might like, but in an OSS community, we sometimes have trouble enforcing what is already there! There's generally an understanding in Dojo that code size is king. The exact measures vary, and there is a certain amount of freedom of expression. The developer who wrote d=dojo probably writes the tightest code, and sometimes it is a bit hard to read, but every byte counts. But the closer it is to the core, the more that is tolerated. Also, certain patterns lend themselves better to the compression schemes used by Dojo.
WDTJ: Adam, bi-directional language support is, as I understand it, a requirement of IBM products. Is BiDi work complete in Dojo 1.0?
Adam: BiDi is not complete. It's targeted for 1.1, which we expect to be available in late Q1 2008, but so far with the help of the IBM Shanghai GCoC lab, we've got BiDi coverage for probably over 75% of the Dijit code. There's documentation on BiDi status in the Dojo book as well as a search in trac for BiDi-related tickets.
WDTJ: Becky, What has been your role in the development of the Dojo toolkit project?
Becky Gibson: My focus is the accessibility of the core widget set. I have worked on Web accessibility for several years, including work on the Accessible Rich Internet Applications (ARIA) specification. We're using ARIA techniques to make the core widget set fully accessible to low vision, keyboard only, and assistive technology users. We support low vision and keyboard only use in IE and Firefox, and screen reader use in Firefox using the JAWS and Window-Eyes screen readers. Dojo is the first open source toolkit to be able to claim accessibility of its core widget set.
WDTJ: What is JAWS?
Becky: JAWS is the most widely used screen reader in the United States and has hundreds of commands for navigating and obtaining information. The more recent versions include more sophisticated scripting support. The JAWS and Window-Eyes screen readers are both doing additional work to support ARIA well.
WDTJ: IBM is focused on accessbility, am I correct?
Becky: Accessibility is very important to IBM and with so many IBM product teams considering Dojo, we needed to make it accessible. I am pleased to announce that the Dojo Core Widget set passes IBM's CI-162 Web Accessibility checklist. The grid widget didn't make it for 1.0 but is a top priority for the Dojo 1.1 release. There is still additional work to improve the accessibility of the core widgets in the 1.1 release. The ARIA specification is nearing completion and will be fully implemented in Firefox 3. This will enable better accessibility of the layout containers and some of the more complicated widgets such as the combobox and the rich text editor.
WDTJ: Who else contributed to accessibility work?
Becky: Accessibility was achieved through a core team of accessibility specialists. There were two folks from the Adaptive Technology Research Centre at the University of Toronto, Simon Bates and David Bolter, who worked on and became committers to Dojo. They were funded through grants from IBM and the Mozilla Foundation to work on Dojo Accessibility. Pete Brunet of IBM also worked on Dojo Accessibility. In addition to actually implementing full accessibility in the widgets, we also helped to educate the Dojo community about accessibility issues. The Dojo community has been very supportive of accessibility and has helped to fix bugs and create themes that support accessibility.
WDTJ: What was it like working on an open source project?
Becky: I have to admit that it took me a bit of time to be comfortable working in an open source community. People "hang out" in the #dojo IRC channel and answer questions and help one another. It took me awhile to build up a rapport with folks and to feel confident in making changes to the Dojo code. All of the Dojo folks are very supportive but it really does help to meet people face to face. Luckily, I have had the opportunity to meet folks at Dojo Developer Days.
WDTJ: Becky, can you describe an ARIA technique you employed in the core widget set? The innards of accessibility work are probably not well known by many readers.
Becky: ARIA defines the role and state metadata to be added to a DHTML control. This information is interpreted by the browser (currently just Firefox) and provided to the assistive technology via the platform Accessibility API. In the case of Windows®, this API is MSAA (Microsoft Active Accessibility). The assistive technology then presents the information to the user. For example, there is no native HTML element for a tree control, so one must be created via scripting. The roles and states for the Dojo widgets are included in the Dojo template and are dynamically assigned when the widget is created. In the case of the tree, the entire tree container is given the role of tree and each item in the tree gets the role of treeitem. If the tree node is expandable, it will get the state of expanded. If the node is collapsed at creation time, the expanded value is false, if it is expanded the value is true. In addition to assigning roles and states at creation time, the states must be updated as the control changes. In the case of a treeitem, if the node is expanded, the state must be set to true; when collapsed the value must be updated to false.
A screen reader user interacting with a Dijit tree control will hear information about the focused treeitem, its level in the tree hierarchy, its expanded/collapsed state, and the number of children, if any. The tree control is navigated via the arrow keys -- just like a tree control in the Windows file manager. Previously, tree controls were created out of lists and links so the user had to tab to each tree item. In the Dijit tree, the user uses the right arrow key to expand a treeitem, the left arrow to collapse a treeitem, and the up and down arrows to move between treeitems.
There are specific APIs in the Dijit system for setting the roles and states via scripting: setWaiRole, getWaiRole, setWaiState, getWaiState, and so on. Roles and appropriate states have been added to all of the core widgets (Dijit) in Dojo 1.0.
WDTJ: Becky, you said "The ARIA specification is nearing completion and will be fully implemented in Firefox 3." What about IE? We developers all love Firefox, but our products -- at least here at IBM -- need to work on IE too.
Becky: The problem is that IE does not yet support ARIA. It requires work on the part of the browser to support ARIA. As stated above, the browser has to interpret the additional role and state information and provide it to the assistive technology via the accessibility API. IBM is encouraging Microsoft to add ARIA support to IE and we hope that support by Firefox and implementation of ARIA in commercial products will help to push the issue. The good news is that the JAWS screen reader, which is the more popular of the Windows screen readers, has been updated to better support Firefox and ARIA. The Opera browser is also working to support ARIA and full keyboard accessibility.
WDTJ: Jared identified a need for help with documentation. Is this a problem in internationalization and accessibility too?
Adam: I can't speak for Becky, but the coding work feels like it's under control in these areas. Documentation is a bit different since, until recently, we were really a bunch of developers focused only on writing code. Occasionally, the subject of documentation would come up -- always the #1 complaint -- and we'd declare that we'd stop coding for a couple of weeks and write documentation. That usually failed miserably. More recently, we've had some really good documentation people join the project, and they've taken the lead in structuring, writing, and editing the documentation so that it's consistent and readable. Developers are actively participating, but the process is being run by people who really understand documentation, and that's made all the difference. I'm really pleased with the new "Dojo Book," our online manual. Still, we're always looking for feedback -- comments can be left directly on the book pages -- and volunteers to help with that effort. Significant work is still needed on documentation-related tools, however. Our API docs are still limping along, and that's a big problem for our users.
Regarding internationalization, we're pretty much done with the Dojo and Dijit codebases. The remaining BiDi issues should be resolved in the next release cycle. As I mentioned, I've had a lot of help from the IBM Shanghai GCoC. DojoX doesn't have the same i18n requirements, but I hope we can eventually bring it up to the same standards, and contributions to support additional i18n features, like non-Gregorian calendars is occasionally discussed; I think for that sort of thing, we could use additional help. The localization process -- actually getting translations in -- happens in two ways. For the initial pass, we can thank the IBM Web Feature Pack 2.0 team for funding the translations and running them through IBM's rigorous test cycles. These translations, I think there were 12 languages, were all sent back to Dojo as open source contributions. Since then, we've had individual contributors provide translations for their own languages. That sort of help is always welcome.
Becky: Since the ARIA techniques we are using in Dojo are fairly new, there wasn't much existing documentation to rely on or refer to. I made an initial pass for the 0.4 book which was updated for 0.9/1.0. The a11y team created an accessibility-specific section in the documentation for each widget. As Adam says, it has been great having people with documentation and writing skills join the project to improve the documentation and its organization.
WDTJ: The open source process is interesting but it might not be very well understood by many readers. For example, who decides what code gets into the toolkit?
Adam: Generally by consensus among Dojo contributors. There are owners for the various modules, and "benevolent dictators" for each project with veto rights.
Becky: Once you reach committer status, you can check code in without review and can check in for others provided they have signed a CLA. But, if you do something that breaks the build, is inefficient, or just plain dumb, you'll be called out by the community, so you need to make sure you know what your are doing! There are experts in the different areas who are available to ask in Internet Relay Chat (IRC) or, if necessary, via e-mail. The Dojo contributors e-mail list is used to discuss new ideas, issues, and proposals before large scale changes are made. Just as with any development project, people must be responsible for the quality of the code and for getting reviews when necessary.
WDTJ: Do you like the open source virtual environment?
Adam: One of the most interesting parts about working in Dojo, aside from getting to know some truly brilliant people, is the culture of an all-online development community. A lot takes place in IRC; except for the occasional social face to face, you never actually talk to the other folks, even though you may work with them all day long. Even the meetings take place in IRC, and that took a while to get used to, but I think they're now my favorite type of meeting! I think a lot more information gets exchanged more accurately, and once you get over the initial feeling of information overload, it's amazing how much you can multiplex! Instead of the usual format of one person doing all the talking, sometimes it feels like everyone can contribute simultaneously, and actually be heard! It's also been fun working with a team truly distributed around the world, talking to people in Asia before you go to bed and saving questions for the European contingent in the morning -- though it's been a bit tough on sleep patterns at times.
WDTJ: How are deadlines or milestones set? By committee?
Adam: By consensus. We generally don't try to plan too far in advance. It's hard to, since many of the committers are part-time or volunteers. We generally focus on one release at a time while maintaining a bug fix release for the previous release. Occasionally, we do a reality check face to face and update our long-term plans and goals, and we try to have face-to-face meetings once or twice a year to discuss things like that.
Becky: Deadlines and milestones seem to be set via "collective intelligence" often emerging from conversations in IRC, weekly meetings, and input and direction from Alex Russell and the benevolent dictators (project leads). That isn't meant to convey that deadlines and milestones are set by chance; significant thought and planning are put into the process and the deadlines are taken seriously, even though they are not always met. This is one of the benefits of IRC meetings -- anyone can speak up and all comments are displayed for all to see -- and read.
WDTJ: Thank you all for your comments!
-
Dojo Toolkit
-
Dojo Widget Library
-
History of Dojo
-
Dojo download statistics
-
Dojo Foundation
-
Using the Dojo Toolkit with WebSphere Portal
Scott Johnson has been a software developer for 25 years. Before joining IBM he worked in the areas of banking, cash management, survey research, and healthcare scheduling and staffing. He joined IBM in 2000 as the JavaServer Pages component lead for WebSphere Application Server. He currently uses Javascript, Dojo and Adobe Flex to develop widgets for WebSphere Business Monitor.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
Easily build dynamic Web page capabilities with the powerful Open Source Dojo programming and WebSphere Portal.
- Try: Save valuable time with easily tailored WebSphere Portal out-of-the-box Internet and intranet example sites.
- Article: Use these advanced Ajax techniques to create dynamic, cooperative portlets with the Dojo toolkit and WebSphere Portal.
- Tutorial: This tutorial takes you through the steps to enable drag-and-drop functionality using WebSphere Portal.
- Buy: WebSphere Portal express
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
