To get started let's discuss why I chose to use Dojo instead of the more popular JQuery toolkit. The primary motivators for me were as follows:
- Dojo's syntax is very easy to read, write, and understand
- Dojo has a fantastic collection of widgets that cover 90% of your needs
- Dojo does pretty much everything that JQuery does
- On demand package loading means you can load what you need, when you need it
- Comes with built in developer tools
To make this an objective post, there are a few downsides to Dojo that I've come accross:
If you've made it to this point you're either already a Dojo coder or you're intrigued by its possibilities. If you are considering trying Dojo, my personal opinion is that you should. Having used both JQuery and Dojo, Dojo wins hands down as the better toolkit, a sentiment that is shared by many of co-workers. This post is not intended to be a rigorous tutorial on Dojo - there are many great books on this such as Dojo: The Definitive Guide - what I intend to do is give you some high level tips that books typically omit.
- It's not as popular as JQuery so it's harder to find new hires that already know it
- Dojo is not as mature JQuery so documentation and code samples are not as easy to come by
- Dojo is significantly larger than JQuery so it's easy to learn but hard to master
- Dojo can become slow when writing a large application with lots of widgets or consuming a great deal of data (more on this later)
Tip 1: Use the Dojo class system
Dojo's class system is fantastic. It allows you to write proper Object Oriented code that you can nicely organize in a package structure. No matter how small a component you may be writing you should always encapsulate it in a Dojo class so that you can later extend it and load it on demand using Dojo's package loader. For those here that are back-end programmers I don't think I have to preach about the benefits of OO programming. Dojo provides it so just use it, it will only take you 30 seconds longer to wrap your code in a class. Dojo does allow for multiple inheritance and I encourage you to use it, but for the sake of your co-workers, document method uses of methods that are defined in parent classes. Unlike back-end languages it's difficult to trace the source of methods that originate up a complex inheritance chain.
Tip 2: Internationalize from the start
Dojo provides a great set of tools for internationalization (i18n). Even if you have no near term plan of supporting multiple languages, it's wise to house all of your copy into one or more master documents should the need for i18n arise. Although i18n is usually tedious, the tools provided by Dojo make it as easy as it gets. Doing this will only add a extra hour or two for each month of work.
Tip 3: REST
Dojo's AJAX package and widgets are heavily geared towards RESTful web-services which is both good and bad. The downside is that if you are trying to reuse non-REST back-end code, you may have to modify the behavior of some of the widget data stores (this is neither fun nor easy). The upside is that the support provided for RESTful web-services is outstanding right out of the box. If you're starting out with a new application I highly recommend you write your application as a RESTful API and build your front-end on top of that API (e.g. Twitter) using Dojo. This will not only make your front-end code clean but you'll simultaneously be developing a platform, not just an application.
Tip 4: Events, events, and more events
Dojo's architecture is heavily event driven, both with standard events and pub/sub style syndication. While event handling used to be tedious affair, it can now be handled with ease using built in tools such as dojo.connect [connect to an event] and dojo.hitch [bind a method call to a specific context]. I therefore highly recommend designing your objects and applications around an events based architecture. If you're tying multiple classes together, rather than passing object or method pointers across these classes, simply trigger events and have sibling or consuming classes connect to them. This allows your components to maintain a loose coupling resulting in a more robust application. Carefully decide when to use standard events vs. pub/sub as there are noticeable differences in performance between these two. If you really do need to broadcast an event to a wide audience where establishing individual connections would be too onerous, go for pub/sub, otherwise stick with standard events.
Tip 5: Go to the source
As I've mentioned, the documentation for Dojo is good but not great. The Dojo team does their best to maintain an up-to-date API and Reference Guide, also Dojocampus provides lots of examples but often times you just can't find what you're looking for. I've found that the best reference guide for Dojo is the source code itself. It is well documented but can be tricky to read. As described above, Dojo is heavily events based so when going over the source it's important to understand what events are being are being thrown and which objects are attached to those events. Debugging Dojo is not easy from the outset but once you learn its structure, it's quite consistent across its various components (with a few exceptions). Spend a day or two going through the source as this will pay off greatly in the long run. As an added bonus, Dojo was written by lots of great programmers, reading their code just might make you a better programmer. Another great tool for discovering the capabilities of an object is dojo.debug(). Simply pass your dojo object into the debug function and inspect it using Firebug's DOM inspector. This will give you lots of details about the objects contents in a runtime environment.
Tip 6: Don't settle
Dojo is designed to have its components extended to suit your specific needs. It will not cover 100% of your use cases so extending functionality will quickly become a reality. Whatever you do, don't change the Dojo source, extending a class may take a bit longer but it ensures that when you migrate to a new version your application doesn't break down completely. When extending a Dojo class, try to use this.inherited(arguments) [call the parent classes method with all the arguments] whenever possible so as to minimize the amount of code you have to copy and paste from the Dojo method you are overwriting. As mentioned Dojo can become slow if your application becomes large and you are using a number of widgets. To overcome this you will have to extend certain Dojo widgets and create optimized versions of methods so that they don't fire any unneeded events, especially if you are performing bulk operations. If you are not using any widgets on your page then you will not encounter any performance issues.
Tip 7: Don't rush it
As programmers we have a tendency to read the first 20 pages of a technical book then hit the ground running, learning as we go. Dojo is no different than any other language, you have to use it to become good at it but I would highly recommend at least skimming an entire book on Dojo before taking on a larger project. I made the mistake of getting half way through the book, then finishing the rest two months down the road only to realize that Dojo has already provided solutions to problems I was running into.
Tip 8: Think like a real programmer
If you have any other Dojo tips that you've discovered while using it, please share them in the comments.
If you liked this post please follow me on Twitter for more.