Documentation and Support
As a new Dojo developer, the first thing you will notice is the lack of sufficient and comprehensible documentation. Though there exists a large amount of information available on the website, this information is not presented in an easily consumable format and many of the examples do not work. To further exacerbate the issue: a simple search on your favorite Q&A site will yield only a handful of results for Dojo, some of which are likely to be from an older version or have otherwise grown irrelevant. For our Proof of Concept phase, developers recorded searching up to 30 minutes before finding material relevant to their query. Yes, there are many groups within IBM that use Dojo and would be more than happy to assist with issues, but these resources are inconsistently available and should not be a developer’s primary resource. To add insult to injury, debugging Dojo in the browser console will drive you crazy.
Conversely, newer frameworks such as Angular and Backbone have an immense amount of community generated content on popular websites, such as stackoverflow, as well as incredibly thorough documentation which is easily digestible and provides detailed examples. Generally, searching for content relevant to an issue for more popular frameworks like these can be found in under 10 minutes, especially when taking cues from the verbose console output in the event of an error.
Markup and Accessibility
Dojo’s Dijit library is incredibly vast and easy to extend; unfortunately, there are also many widgets that are under-tested and lack conventional, semantic HTML. In some cases, even if you define widgets declaratively, Dijit will rewrite your HTML and cause severe headaches when attempting to apply custom structure or style to your application. Fortunately most widgets are highly accessible and include tags to make them screen reader friendly, but the question remains: If Dojo did not use proprietary HTML structure for its widgets, would the additional accessibility tags be necessary?
After examining a modern UI library, Twitter Bootstrap, the answer is obvious: kind of. Since Bootstrap provides styles and only suggests how to structure your HTML, you are free to customize your markup however you wish without fear of it being manipulated. In their suggested markup they provide use cases for ARIA tags which, when used, reduce the need for additional accessibility development, (which can also be provided by 3rd party libraries). To match the highly dynamic and reusable nature of Dijit’s widgets, templating libraries such as Handlebars can be used to roll custom widgets which are reusable like Dijit’s while retaining complete control over the structure of the markup.
Code Structure and Maintainability
Aside from Dojo’s heavy use of AMD there are few useful conventions in place for how to structure a Dojo application. Many Dojo applications drift apart in how the code is structured as well as how they communicate with external APIs, which can make maintaining a project and ensuring forward compatibility an issue. Dojo does provide a testing module, however, Dojo as a whole is by no means a testing-first library.
Other frameworks, namely Angular, have strong opinions about how code should be structured and do enforce a testing-first development methodology. This is not to say that Angular is less flexible than Dojo; to the contrary, it simply provides an underlying structure on which models and views can be logically tied together. This structure is also used to promote RESTful interaction with external resources and a stateful persistence, even in single page applications, which you only get in Dojo by adding additional modules that need to be carefully configured.
Our Chosen Framework