Slashdot Mirror
Dojo: Using the Dojo JavaScript Library
stoolpigeon writes "The number and functionality of web based applications has exploded recently. Many of these applications rely heavily on AJAX to provide a more desktop-like experience for users. As the number of people using JavaScript grew, libraries were developed to assist with commonly encountered issues. Jim Harmon's new book Dojo: Using the Dojo JavaScript Library to Build Ajax Applications aims to introduce readers to one of those libraries, the Dojo Toolkit." Keep reading for the rest of JR's review.
Dojo: Using the Dojo JavaScript Library to Build Ajax Applications
author
James E. Harmon
pages
316
publisher
Addison-Wesley Professional
rating
7/10
reviewer
JR Peck
ISBN
978-0-13-235804-0
summary
a complete example rich developer's guide to Dojo
The Dojo Toolkit, is a JavaScript library, created to increase the speed of writing JavaScript applications. It provides developers with widgets, themes, wrappers for asynchronous communication, client side storage and more. It does all this across various browsers and platforms without requiring the user to worry about differences in browsers.
The book follows an interesting pattern. It begins with a five chapter tutorial. The tutorial launches immediately into taking a straight html form and using Dojo widgets to add functionality. All of the code used in the tutorial is available at the book's web site. This tutorial moves quickly, introducing a number of available widgets and giving the reader a nice feel for how Dojo integrates with html markup.
What does not take place in the tutorial is the normal introductory material on just what Dojo is, how it is installed, or what it can do. I'm guessing that this will be a welcome change to those used to quickly brushing past the first chapter, or more, of any programming book. Harmon takes advantage of the fact that Dojo is available via the AOL Content Delivery Network, so the examples will work any javascript capable browser connected to the internet. He does give a quick explanation of what would need to be different to use local files.
All of the introductory material that I'm use to seeing is still in the book but it does not appear until chapter ten. There Harmon covers the motivation to develop Dojo, explains the history of the project, provides a bit of information regarding the dual-licensing of Dojo. (It is available under the BSD and Academic Free Licenses.) This leads into the last seven chapters, that cover the 'deeper' material in the book.
Between the tutorial and chapter ten, there are four chapters of widget documentation with examples and some explanation. Of the three sections this is the longest, though this is in part due to sometimes large sections of white space, as each widget begins on it's own page. The documentation covers each widget and provides a visual representation where applicable. There is some repetition as this section covers widgets that were used in the first section's tutorial.
The third section is entitled "Dojo in Detail." It's the level of detail that marks this book as more of an overview, rather than an in-depth treatment of Dojo. Harmon is true to the title, this book is an extremely pragmatic guide to getting started with Dojo as a means of adding Ajax to applications. It is not however going to take the reader to any great depth into the toolkit. There is plenty here to get started, and enough to hit the ground running, but anyone to get really in-depth coverage of the library will be disappointed.
The person who will get the most out of this book is someone with some knowledge of mark-up and programming but not to an advanced level. The developer with a lot of experience will probably be frustrated with the amount of explanation and repetition of simple material combined with the lack of depth. The reader with no programming experience may struggle, though they could keep up if they are willing to look outside the book for a few resources to get a good grasp of web technologies. They may become extremely frustrated with some of the later chapters where the code examples skip steps and leave the reader to assume what has happened in between what is shown and the output.
That said, this book allows the reader to dive in quickly, get a quick overview and move immediately to making use of the Dojo Toolkit. If one is not concerned with gaining insight on every aspect of the library but would rather just get into it immediately with a little guidance, this may be just right.
With this in mind, it would have been nice if the book had provided less time on documentation and more on examples and ideas for how to best use the capabilities of Dojo. It is nice to have a book that isn't so huge that it is overwhelming and difficult to find anything. But if something had to be given up to keep things compact, I'd have much rather lost things that are easy to find in the on-line documentation and subject to change as the toolkit develops. This keeps the book from being excellent, but it is still a solid introduction and primer.
You can purchase Dojo: Using the Dojo JavaScript Library to Build Ajax Applications from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
The book follows an interesting pattern. It begins with a five chapter tutorial. The tutorial launches immediately into taking a straight html form and using Dojo widgets to add functionality. All of the code used in the tutorial is available at the book's web site. This tutorial moves quickly, introducing a number of available widgets and giving the reader a nice feel for how Dojo integrates with html markup.
What does not take place in the tutorial is the normal introductory material on just what Dojo is, how it is installed, or what it can do. I'm guessing that this will be a welcome change to those used to quickly brushing past the first chapter, or more, of any programming book. Harmon takes advantage of the fact that Dojo is available via the AOL Content Delivery Network, so the examples will work any javascript capable browser connected to the internet. He does give a quick explanation of what would need to be different to use local files.
All of the introductory material that I'm use to seeing is still in the book but it does not appear until chapter ten. There Harmon covers the motivation to develop Dojo, explains the history of the project, provides a bit of information regarding the dual-licensing of Dojo. (It is available under the BSD and Academic Free Licenses.) This leads into the last seven chapters, that cover the 'deeper' material in the book.
Between the tutorial and chapter ten, there are four chapters of widget documentation with examples and some explanation. Of the three sections this is the longest, though this is in part due to sometimes large sections of white space, as each widget begins on it's own page. The documentation covers each widget and provides a visual representation where applicable. There is some repetition as this section covers widgets that were used in the first section's tutorial.
The third section is entitled "Dojo in Detail." It's the level of detail that marks this book as more of an overview, rather than an in-depth treatment of Dojo. Harmon is true to the title, this book is an extremely pragmatic guide to getting started with Dojo as a means of adding Ajax to applications. It is not however going to take the reader to any great depth into the toolkit. There is plenty here to get started, and enough to hit the ground running, but anyone to get really in-depth coverage of the library will be disappointed.
The person who will get the most out of this book is someone with some knowledge of mark-up and programming but not to an advanced level. The developer with a lot of experience will probably be frustrated with the amount of explanation and repetition of simple material combined with the lack of depth. The reader with no programming experience may struggle, though they could keep up if they are willing to look outside the book for a few resources to get a good grasp of web technologies. They may become extremely frustrated with some of the later chapters where the code examples skip steps and leave the reader to assume what has happened in between what is shown and the output.
That said, this book allows the reader to dive in quickly, get a quick overview and move immediately to making use of the Dojo Toolkit. If one is not concerned with gaining insight on every aspect of the library but would rather just get into it immediately with a little guidance, this may be just right.
With this in mind, it would have been nice if the book had provided less time on documentation and more on examples and ideas for how to best use the capabilities of Dojo. It is nice to have a book that isn't so huge that it is overwhelming and difficult to find anything. But if something had to be given up to keep things compact, I'd have much rather lost things that are easy to find in the on-line documentation and subject to change as the toolkit develops. This keeps the book from being excellent, but it is still a solid introduction and primer.
You can purchase Dojo: Using the Dojo JavaScript Library to Build Ajax Applications from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Nobody cares?
Story has been up for a while and this is the first post!
Why isnt this under book reviews?
javascript is pants.
Of course, the real problem comes when dojo destroyers come to challenge your entire office.
Seriously. We paid good money for that damned sign.
I'm just starting out with javascript. I've only done bug fixing on existing sites, and have never used a framework. What are the pros and cons of Dojo and jQuery?
I'll be the first with something relevant here. We use the Dojo tooltips and toaster widgets at work. They come in handy. Easy to use and very customizable. The tooltips have a few flaws but nothing that you can't easily work around.
"I don't have to think. I only have to do it. The results are always perfect, but that's old news." - Meat Puppets
Not sure I wanna use something called Dojo with the threat of Shodan still around... ;)
Close. I'd like to see an all out brawl between the supporters of Dojo, Jquery, Prototype, and any others I've neglected to remember. The book and or the review should have mentioned the competing libraries and the particular advantages of Dojo. That would be helpful. Telling me that the book about dojo explains how to use dojo is not. Its a waste of time for most slashdotters.
Well.. maybe. Or Maybe not. But Definitely not sort of.
Some annoying wanker keeps tagging everything "Story", even if it's not a "Story". Please stop doing this.
Anyone else read that as "DOJ: Using the DOJ JavaScript Library"?
Well, I'll tell you one thing: IBM is a primary sponsor of the Dojo foundation. Not so for jQuery and prototype. If IBM isn't a good enough reason to stay the heck away, I don't know what is.
blah blah blah
since, if you got any mojo, you can get some girls (ask Austin Powers if you don't believe me). if you got some dojo, you cannot get anything?!
Read and Comment at my BLOG
!!!
I'd like to take this opportunity to start a holy war between Dojo and Scriptaculous/Prototype. Aw hell, why not throw in Ext too.
Wait, I'll get some popcorn.. OK - Go!
Is Dojo even relevant anymore now that Microsoft has embraced jQuery?
I bought "Mastering Dojo" and although I have not finished it yet, I like it. I got into using Dojo a few years ago when I was experimenting with Common Lisp back end code with a REST architectural style - and a rich client Dojo web interface. Dojo is very cool. I have also used Dojo in a Rails web app and tried it with a JSP based web app (just a test, not a real project).
The other related book I bought recently is "Javascript, The Good Parts" that has made me appreciate the language more.
dojo is natively supported by the Zend Framework (from version 1.6 onwards).
That may be enough on itself as a deciding factor for you... or not. Since I wanted to start with any of this Javascript libraries, the fact that ZF supported this one made my choice much easier.
Dojo documentaion is slowly getting better, but it is still sorely lacking.
O'Reilly has two other books for dojo: Mastering Dojo and The Definitive Guide.
I think you'll be disappointed to find out that the creators of Dojo (including me), jQuery, and Prototype actually get along really well, and are starting to discuss working together to share code and concepts more formally across our toolkits.
As far as advantages of Dojo, in general, we let you build complex, advanced apps with things like native vector graphics, charting, grids, etc., but can still scale down and perform for even the smallest of features or unobtrusive JS. We also lead the charge in areas like accessibility, internationalization, etc.
-Dylan
Funny you say that.. i just went to the AJAX Experience conf this month in Boston. The dev'ers of the four big ones were on stage together (+ Yahoo!). Things were a bit tense once in a while, but for the most part, they were polite.
I'm sorry to answer my own post, but I just wanted to add: if industry support is the thing tilting you one way or the other, maybe you should consider that jquery recently got embraced in different ways by both Microsoft and Nokia.
So depending on your on your needs, it could go either way. Featurewise, I think that both are pretty solid.
I.-
I was recently looking for a javascript library to help solve cross browser issues with accessing ASP.NET based web services. The main interest was DOM traversal, simple GET/POST/SOAP requests, and XML parsing. I looked at a bunch of different frameworks, but finally settled on jQuery. It had everything that I needed in a small package with excellent support for plugins and add-ons. We ended up using an XML to JSON converter plugin since parsing arbitrary XML can be a pain to do in a cross browser world. Keep in mind that we did not use any of the UI or effects portions of the libraries, but if you are looking for an easy way to create javascript that will work in most major browsers I suggest jQuery.
The big, big, big issue is documentation. Other things being fairly equal, the library that is explained best will get used more, and receive much more support.
It's said when EVERY user must do extra work, rather than just one writer.
I can't help but think that all of these JavaScript/AJAX libraries keep reinventing the wheel over and over again. How many grid widgets written in JavaScript do we really need? How many toolkits for a progress bar or a div-based dialog box have to be developed? Is one of them really that compelling over the others. Consider:
http://dojotoolkit.org/ - DoJo Toolkit
http://www.activewidgets.com/ - ActiveWidgets
http://www.prototypejs.org/ - Prototype
http://script.aculo.us/ - Scriptaculous
http://jquery.com/ - jQuery
http://extjs.com/ - Ext JS
http://developer.yahoo.com/yui/ - YUI
http://code.google.com/webtoolkit/ - Google Web Toolkit (GWT)
http://www.sproutcore.com/ - SproutCore
Those are just the ones I have used personally. It's getting ridiculous. Personally, I like the approach GWT has, but of course that's only relevant to the java developers of the world. I'd love to see all of these "widgets" be compatible with one another.
- Vincit qui patitur.
Interesting. The violence I was hoping for was only metaphorical in nature. Competition is only good when there is an ability to differentiate the offerings. I think I'll have to take a look at DOjo then. Native vector graphics sounds great.
Well.. maybe. Or Maybe not. But Definitely not sort of.
Being a practical type, I must confess that the learning curve with Dojo has been rather steep; having said that, once you get over the first major hump - it's literally all downhill from there. But, I'm not defending Dojo. Instead, I'm complimenting the book.
This book appears to solve the learning curve problem by starting with a practical tutorial and then going into guts.
IMO, the biggest problem with Dojo's userbase growth has been that Dojo seems to be both large and small at the same exact time, making it difficult to get oriented. One thing that developers should keep in mind is that Dojo is very scalable; performing a custom build will whittle it down from its 37+ MB source distribution (yes, graphics included) to however low you need it (in my case, couple of hundred kilobytes - smaller than some logo images out there).
In my case, I've completely embraced Dojo as a reliable way to quickly produce backend systems with it - and - more recently - front ends.
But that's just work. As for fun - without Dojo, I don't think that I would have put my open source project together or released it to the public. There are so many hours in a day and I don't have time to reinvent the wheel; Dojo was there for me.
For some amusing interaction between Dojo and PHP (not using the Zend framework..), see the videos / screenshots from http://eval2.sourceforge.net/
Dojo has some cool and impressive examples (the fish eye menu is kinda neat). However,everytime I've looked at Dojo and tried to figure out how to use it, I've had to walk away shaking my head. It is usually easier to implement something myself instead of trying to figure out the all the undocumented spaghetti code and "helper" files and abstractions in Dojo. Dojo seems to have taken all the complexity jokes about java and ported them to javascript. Maybe they have gotten better in the last year or so, but the last time I looked, most of it was undocumented and the code as non-trivial to decypher.
For people who want to use some simple, yet powerful JS/Ajax/CSS, I'v been recommending that they check out BrainJar. Brainjar has some pretty neat stuff that is much easier to figure out, although its random stuff and not a comprehensive toolkit. But brainjar will give you some neat ideas of the things you can to with JS and CSS. Check out the windowing demo and as a plus it won't screw with your mind like Dojo.
i can't help but think that all these cars keep reinventing the wheel over and over again. how many four-wheeled gas-powered automobiles do we really need? how many cars with driving wheels or airbags or cupholders have been developed? is one of them more compelling than the other?
not everyone programs in the same style. not every toolkit is suited to the same programming style. it's good that web developers have a variety of toolkits to choose from. are all the different CMS packages out there reinventing the wheel? what about all the programming languages? all the operating systems? there isn't just a single approach to every problem. the toolkits that are useful will gain a large following and continue to be developed. the ones that aren't will fall into disuse and die. there's no sense in complaining about choice.
I've completely embraced Dojo as a reliable way to quickly produce backend systems with it - and - more recently - front ends.
Producing a 'backend' system with a JS library must be a neat trick, since JS is client side. However, I totally agree with you about the learning curve. I couldn't make heads-or-tails of the code.
How does Dojo compare to Yahoo UI (YUI)?
is competition good, or is duplication of effort bad?
Close. I'd like to see an all out brawl between the supporters of Dojo, Jquery, Prototype, and any others I've neglected to remember.
Obviously Dojo would win, given the fact that it has produced hundreds of exceptional fighters in its time.
Should be: "It's sad when EVERY user must do extra work, rather than just one writer."
I have to say a word of agreement here; GWT blows the pants off of anything else I can find
Forgive my ignorance here, but why is Google using jQuery in their Google Code site if they could have used GWT?
Reply to That ||
stoolpigeon = Jim Harmon
Hello Jim,
Enjoying free publicity?
I still don't understand why anyone would want to use JavaScript for web front-end development. It's just insane.
And I think I should point out that I'm not saying this because I dislike JavaScript as a language or do not have enough experience with it to know what I'm doing. As a scripting language, I like it and have used it on the server side in a few instances where we needed the ability to dynamically run code on the server without re-deploying our application. And I'm part of a team that was tasked with re-writing our entire application as a "Web 2.0" (I hate that term) application.
So lest anyone think I'm just trying to say something inflammatory, my comments come from 2 years of hands-on daily usage of JavaScript and I even understand what is involved in writing a JavaScript framework that will perform in all of our target browsers (IE6+,FF2+,Safari2+).
Because at the time (roughly 2 years ago) when we set out to re-write our application, none of the available JavaScript-only libraries performed up to our needs...it seems that none of them make performance a priority. Sure most of them allow you to quickly make simple pages that are pretty to look at, but once you get to something moderately complex, the page gets unacceptably slow in at least one browser (almost always IE6, but rarely the other browsers get in on the act too). They all pretty much fall prey to one of the many "gotchas" when it comes to JavaScript (excessive object creation, excessive DOM traversal, etc).
So we ended up rolling our own. It wasn't the kind of thing that could be released publicly since it relies almost entirely on convention rather than strict APIs, but with a lot of work we were able to get it to perform the way we need it to. Along the way, we've written approximately 3000-4000 jsunit tests, so that should give a pretty good picture of the combined size of the framework and application.
And yet even with this accomplished, it still took an excess amount of time to develop front-end functionality and there were still a ton of bugs in the UI (mostly in IE6) that we couldn't seem to catch with automated testing. And that burden on QA was eating all their time preventing them from having the time necessary to test back-end logic in a comprehensive fashion.
So about 3 months ago we determined to do another evaluation of the JavaScript libraries available. And once again, none of the pure-JavaScript libraries was up to handling our test page (not our most complex, but close to it).
But what we did find was that GWT has evolved to the point where we can use it and, simply put, it smokes even our own framework when it comes to performance. We had dismissed it immediately when we did our original evaluation since it made it too difficult to embed it into existing pages, but that's no longer the case. It allows us to leverage our Java expertise, since we write our back-end in Java. It allows us to write our unit tests for the front-end in JUnit and run them along side our back-end tests in our continuous integration setup. We've cludged together a means of doing the same for JSUnit, but it requires individual "worker" machines that run the tests on each browser, which makes the tests take forever to run. As we replace all our JSUnit tests with JUnit tests, the time necessary to do a continuous integration build is steadily decreasing, and faster build times lead to less time when the build is unstable.
So now we're developing all new pages in GWT and slowly replacing existing pages. And while there still are bugs in the UI, the defect rate in our GWT-based pages is at least an order of magnitude less than we had using JavaScript. And when we do get bugs, they get fixed faster since hosted mode gives us a real debugging environment.
And it's this experience with GWT contrasted with the experience both writing/using our own framework and doing a ton of test pages with the various frameworks that leads me to the original question...Why would anyone want to use JavaScript anymore? With all the advantages that GWT gives without any real down side, why would anyone subject themselves to the pain of developing in JavaScript?
I'd like some non-native vector graphics. Where do I get it?
Honestly, fuck dojo. Javascript does not need libraries. Old people get their hands on every language and try to make it more complicated that it needs to be / is.
dojo would win hands down, no question!
Ok something that must be said here that seems to have been overlooked. Dojo is actually unusable - and yes I mean that perfectly seriously - unless you have somebody around who already has experience with it. It is completely undocumented - the documentation that exists is sketchy and often wrong. No just listing the class method parameters automagically is not sufficient. My workplace has just ditched Dojo and is investigating JQuery - with some success thus far - purely on this basis: Dojo is unmaintainable and very slow to work with because of the complete failure to document it and provide good examples. Its a pity because some of the Dojo widgets are very cute and work very well - if you can ever figure out how to use them. I'm sure this book will help enormously - but I regard it....no, it has to be regarded - as a vast looming FAIL that a book is *required* to use a library, particularly when its just a JAVASCRIPT library too. Dojo widgets are also overly-clever in some areas, eg. simple collapse trees don't exist, and this is a major letdown - shops with requirements for cleanliness and maintainability will not use the magic mojo, they will go with simplicity (eg. JQuery) instead. In summary: Dojo = FAIL for me/us, mainly for documentation reasons, and its a crying SHAME.
Totally agree Arkham, and some of them are so 'wanky' it begats pointless. Dojo is a culprit here too.
it has a fatal flaw.
It is built around the idea of using the dojoType attribute to declare dojo wigets.
But dojo type isn't a real attribute! Modern browsers only accept it because they have to accept all sorts of garbage for html. If you are trying to serve xhtml, it will break your shits.
So, I'd say it's fatal flaw is lack of decent xhtml support. Xhtml has the concept of namespaces that should make custom elements easy... so I don't know why they've left things like this.
"How many grid widgets written in JavaScript do we really need?"
how many <insert widget name> do we need ? Just one. But one that works.
I had been caught numerous times with some code that did 90% of what I needed, and then you have the choice: hacking existing code, alone or with the help of primary author -or- creating a new wheel.
I ended up myself reinventing the wheel again and again because that was simply the easiest thing I could do, adding more noise to the crowded debate.
Give me the browser that implements the high level widgets everyone need, and I'll be extremely happy.
Ahh, ok, we need to get the standard first... Jeez...
If JSONP isn't an option for you, and you need to make use of a REST endpoint on another domain (or even subdomain), see if you can get the service provider to add Dojo's XIP server files to their server.
Have you driven a fnord... lately?
You must wait a little bit before using this resource; please try again later.
I browsed around the web for Dojo examples, and only about half worked. Not a good sign. Some outright crashed, others half-worked with things like text in the wrong place or only deletion working but not insertion. Reminds me of Java applets a decade ago.
Table-ized A.I.