Debunking Dojo Toolkit Myths

By on October 27, 2008 9:46 am

The Dojo Toolkit has been around for over four years, and has undergone significant changes, both big and small, in becoming a great JavaScript toolkit. This article debunks myth and outdated assumptions (both fair and false) applied to Dojo over its four plus years of development.

Dojo is Undocumented

Far from it! Early on, Dojo’s only documentation was the source code. Today, we have a tremendous amount of information available, and we’re working to better organize and refine it.

To start, take a look at the Dojo QuickStart Guide, Dojo API Viewer, and Dojo Campus Documentation Project (the forthcoming replacement for the venerable Dojo Book).

Want offline docs? Check out the Dojo Toolbox for now, and soon the Dojo Campus Documentation Project.

Need a book? There are now four great dead tree Dojo books to choose from.

Need a great how-to or walthrough? Try one of these in depth Dojo tutorials.

Want to see demos? Look at the Dojo Campus Feature Explorer or the Dojo Spotlight.

Need hands-on Training? Contact SitePen for assistance.

Will Dojo continue to simplify and improve its documentation? Absolutely, and we welcome your help and feedback.

Dojo is Slow

Any JavaScript library can be slow if used incorrectly. In the days of Dojo 0.4, it was too easy to create apps that were slow by having the parser on by default, and include extraneous files and source code.

Today, the parser is a problem unique to Dijit. Dojo != Dijit, and today you only accept the performance hit of a parser (one that is much less than the days of 0.4) when you need a full-featured widget system.

For the past 18 months, Dojo has made it easy to create things with Dojo that are lean and fast, and any functionality that was in Dojo 0.4 is at least 100% faster in Dojo today, and some things are 1000% faster or more. In measuring performance with querying, dojo.query is as fast if not faster than other major leading toolkits with the SlickSpeed test suite.

And Dojo offers a plethora of performance optimization techniques and suggestions to squeeze every last KB and millisecond out of your source code. Reliable, cross-browser performance is a data-driven art that requires leaving many assumptions at the door, listening to data, and making compromises as necessary.

Dojo is Bloated, Larger and More Complex than Prototype, jQuery, MooTools, YUI, etc.

Dojo is designed to give you the necessary tools to solve complex engineering problems, while keeping the simple things simple. This myth exists simply because we use a package system, and we expect developers to leverage a build tool in production code to optimize performance. If you download the full Dojo source, you will see many files. Out of all of those files, you only need to include a single one with a script tag in your markup.

We make it easy to get started by just including dojo.js from AOL or Google’s CDN services. We call dojo.js “Dojo Base”. It is 26KB (gzipped) in size, and comparable in size, features, performance, and functionality to other major toolkits.

Dojo Base provides an extremely rich and lean set of functionality useful to any web developer. I think you’ll be hard-pressed to find more functionality and performance in less KB.

If 26KB is too much, you can even get a stripped down version of Dojo in just 5.5KB, which represents the module loading framework for Dojo, and then add back just the exact features you need. You can also take the entire source Dojo SDK and reduce it down to what you need.

In the browser, every feature adds a slight performance hit, so Dojo values the flexibility necessary to include just what you need, and no more, while offering a wide amount of features in a coherent, organized manner. If you want to use more of Dojo’s functionality, it’s completely optional, and you just dojo.require the extra features you need. The class structure in most cases just follows the logical path structure of your project. For example, dijit.foo.Bar would be expected in /dijit/foo/Bar.js.

The simple provide and require namespace system system makes it easy to use Dojo code and your code alike. This makes it possible to easily create advanced, powerful applications as well as simple features such as the Dojo Flickr Badge.

The Dojo Package system, while adding a bit of complexity that takes two minutes for new developers to learn, makes it much more readable and organized, and provides you with the ability manage your code when script includes and dependencies otherwise become unwieldy. Dojo is a library, and behaves as such. Like Java and many other languages, we automatically include only the bare minimum amount of code, with plenty of other packages that you have to include manually.

There are frameworks within the various libraries inside Dojo, the most widely-known one being Dijit. The Dijit widgets have dependencies on the framework code. These sort of long dependency chains are rare within Dojo, but exist when needed to provide more involved functionality.

Dojo Requires Java

No, not at all—even though the full Dojo SDK does include a few jar files.

In addition to browser-based capabilities, Dojo provides completely optional Rhino-based tools to optimize your code in a build step to improve performance. Rhino is the Mozilla Foundation’s JavaScript engine implemented in the Java programming language.

Why would you ever want to “build” JavaScript? To reduce the size of your source code, to optimize caching, and reduce the calls to the server. For example, you can merge CSS rules together, and take HTML resources used by widgets and turn them into JavaScript strings to reduce the number of HTTP requests, overall file size, and more.

Dojo is Verbose and is “Java for JavaScript”

The only thing in Dojo that resembles Java is our desire to include things in namespaces. Our library structure still encourages brevity, with Dojo Base features living in the dojo.* namespace. Dojo prefers dojo.byId and dojo.query over $, though it is easy to roll your own Dojo bling function if you prefer!

Dojo prefers putting everything in namespaces to reduce our footprint in the global namespace, to allow Dojo code to coexist with other libraries and user code without naming conflicts. Also, Dojo minimizes function overloading, so using full APIs helps with code maintenance.

For brevity, anything that is widely used typically makes its way into the top level namespace in a short and easy to remember manner, e.g. dojo.connect and dojo.attr. The terseness of our API and namespace structure tends to surprise people who haven’t used Dojo since 0.4 or earlier.

Each component is a distinct “thing” and our only options are to address this in the global namespace which would create conflicts, or to hang it off of Dojo. Admittedly, some projects and toolkits don’t have namespaces simply because they don’t provide enough code to need namespaces.

Java developers do like Dojo (or DWR or even GWT or Ext), most likely because of the breadth, depth, and organization of the Dojo Toolkit APIs.

Much of the inspiration for Dojo is derived from Python, AOP, PHP, Java, and a variety of functional programming language constructs like hitch, mixins, delegation, and more. However, we explicitly avoid using any patterns from other languages, and we make great efforts to make our JavaScript leverage the patterns unique to JavaScript.

Toolkit constructs such as dojo.declare() may be considered Java-like, though most libraries have some sort of constructor and inheritance model. Dojo takes advantage of the flexibility of JavaScript rather than trying to provide a domain specific language on top of JavaScript.

Dojo is only Useful for Enterprise Apps and not for Small Sites or Blogs

This myth exists because Dojo was not as small and simple in the Dojo 0.4 days as it is now.

Dojo Base at 26KB gzipped or Dojo Mini down to 5.5KB, both with the same easy to use API, make it possible to do simple progressive enhancement or unobtrusive JavaScript, handle events, Ajax, animations, DOM, querying, and more.

Dojo is Not for Single-Page Apps

The developers from Cappuccino, Objective-J, and Sprout Core argue that they created their efforts because other toolkits are not optimal for true applications in the browser. In our opinion this is rubbish.

Dojo is used widely in feature-rich applications by a variety of companies, such as Sun Convergence, Cisco’s WebEx Connect and IBM’s Project Zero. Dojo is also very widely used for creating applications that live inside the firewall in what I call Ajax Dark Matter.

Dojo is not for Multi-Page Apps and Web Sites

While it’s unlikely that anyone believes both this myth and the previous one, this viewpoint is based on perspective. Given the perceived bloat and toolkit size, some people have suggested that Dojo not be used for multi-page sites, but Dojo’s extensive optimization options make this usage scenario a snap. The Eye-Fi Manager and even the Dojo Foundation web site itself show how snappy these apps and sites are.

Dojo is Just About Widgets

Dojo has a highly flexible, and extremely fast widget system called Dijit. This is a completely optional package for people needing to use and create their own widgets. It is designed to handle a variety of use cases in a modular manner, including accessibility, internationalization, layout, containment, templating, and much more. The underlying concept is that each widget is simply an HTML template, a CSS template, and a JavaScript file for logic.

Many of our users never even touch Dijit.

There are other ways to get lightweight reusable behavior on the fly, including Dojo’s implementation of the Django Templating Language (DTL).

Interest in Dojo is Waning

Why do people think this? Perhaps it is from badly argued stats. People do things like compare Google stats for searches like “jQuery JavaScript” “Prototype JavaScript” “Dojo JavaScript”, etc. because the words on their own conflict with general search terms. Lies, damn lies, and statistics, right?

While interest in other great toolkits has also grown significantly, the usage of Dojo continues to grow aggressively, based on the number of deployed applications, downloads, site traffic, books sold, and a variety of other usage statistics. By all appreciable measures, interest in Dojo is growing faster than ever.

Ajax has become increasingly more popular, and JavaScript is now considered a real language. Dojo has always treated JavaScript as a first-class language, and has a stricter focus on utility than on one particular aspect of the workflow, such as the DOM.

Dojo Doesn’t Validate

A long standing complaint is that Dojo doesn’t validate. DTD != valid HTML. Custom attributes have always been valid HTML, they just don’t validate when tested against a DTD.

If DTD validation is truly important to your project, it is simple to use Dojo with graceful degradation as well; the use of custom attributes is an implementation pattern only, not a hard requirement for using Dojo. Or you can always create a DTD.

In addition to performance benefits and efficiencies of custom attributes, they are a lot friendlier and human-friendly than other options. For example, some toolkits use the rel attribute, and stuff it with data. jQuery’s popular meta plugin looks like this: “<div class=”hilight { background: ‘red’, foreground: ‘white’ }”>”. Why is this better than this non-real, but Dojo style markup: “<div jQueryType=”hilight” background=”red” foreground=”white”>”?

The HTML specification states that any attribute not recognized is to be ignored by the HTML rendering engine in user agents, and Dojo optionally takes advantage of this to improve ease of development.

Dojo is Ugly

Creating beautiful web applications is about having a great sense of style, and interaction/user experience design capabilities. Dojo provides 3 professionally designed themes: Tundra, Soria and Nihilo. If you would like to make them look better, or create a new theme, then get involved!

Dojo’s themes are deliberately understated to make it easier to drop components in alongside existing designs and brands. But at SitePen, in our work with clients we’ve applied our CSS and design skills to Dojo-based applications to create excellent designs and amazing experiences.

Sun Convergence

Eye-Fi Manager

Sensei

Many other companies are also succeeding with theming their Dojo-based applications.

ESRI Site Selection and Trade Analysis Area

Dojo Doesn’t Offer Certain Features Provided by a Particular Library

This may be the case, or it might be called something different or available through a different API style. But Dojo offers extreme flexibility. For example, check out Peter Higgins work to add the missing jQuery API footprint he likes to Dojo in less than 1 KB.

Dojo Doesn’t Work with a Particular Toolkit, Environment or Server

We go out of our way to make sure Dojo works with everything, even when a toolkit or server doesn’t behave the way we’d like. If something is not working for you, just ask on the Dojo Forums or through SitePen Support, and if there’s a bug, file a ticket and it will get fixed ASAP. We’ve gone to great lengths to make sure Dojo works well with popular toolkits, as well as in a variety of environments including: XUL, command-line, Jaxer, AIR, etc., support for initiatives by the OpenAjax Alliance, as well as integration with DWR, Persevere, Zend Framework, IBM Websphere, Django, Ruby On Rails, and much, much more.

Dojo was initially started to stop reinventing the DHTML toolkit wheel, with the original Dojo source code based significantly on the work of earlier toolkits such as netWindows, BurstLib, and f(m).

The People at Dojo Don’t Like a Particular Project

In general, on an interpersonal level, we’re friends with the people creating jQuery, Prototype, YUI, MooTools and more. While Dojo developers of course have differences of opinion in the best approach to development (great developers should disagree, as long as they keep the debate focused on merit rather than the form of the message), we find that fans of Dojo and other toolkits attempt to make things a bigger rivalry than toolkit authors do. After all, we are talking about open-source toolkits that are liberally licensed (BSD, AFL, MIT, Apache, etc.), so it’s hard for us to not get along. Alex Russell, Peter Higgins and I are also on record as inviting other toolkits to collaborate and cooperate to again stop reinventing the wheel.

Ajax Experience Panel with People from Prototype, YUI, jQuery, and Dojo

In many cases, this is a matter of perspective. I know that many of us get bugged because so much of the mud flinging happens not because someone’s done something wrong, but because features of a particular toolkit are criticized because the person doing the criticizing doesn’t understand why those features even exist in a particular toolkit.

It is difficult to contribute to Dojo or Get Involved

Unlike most other toolkits, Dojo requires a CLA which protects your IP rights, and also requires that when you contribute code, you have the right to contribute it. The Dojo Foundation does this to ensure that we are able to redistribute every piece of code in the Toolkit completely free and with liberal licensing. It’s a simple process that should take at most fifteen minutes, and it is well worth the effort. For more information about getting involved, contributing, donating, visit the Dojo Foundation and Dojo Toolkit web sites, or visit the Dojo IRC channel on irc.freenode.net in #dojo.

Dojo lacks Commercial Support

A number of companies including SitePen offer Dojo development, support and training services. The Dojo community offers great free support, but when an issue goes beyond what is reasonable to ask of a volunteer, or needs to occur immediately and/or under an NDA, companies like SitePen are available to help you get productive, from fixing a bug in Dojo to building and designing your entire application.

Summary

As you can see, Dojo has come a long way since its initial creation 4+ years ago. Over the next several months, Dojo developers will continue to improve the toolkit source code, documentation and marketing to make Dojo easy to use regardless of the type of application or web site you are developing.

I hope you will make the decision to use, or not use, Dojo based on merit, rather than on myths or information that is no longer or was never accurate.

Comments

  • Les

    Dojo is an extremely well thought out and powerful library. I developed the front-end for SlippyMap using Prototype and OpenLayers. If I had to do it again, I’d use Dojo and OpenLayers.

    I highly recommend Dojo for medium and large projects.

  • Hi Dylan,

    Just thought I’d chime in (re:Cappuccino). First, I think Dojo is an impressive project, and a lot of talented programmers have worked on the code. Clearly a lot of thought and effort has gone into its development.

    I don’t believe we’ve ever compared ourselves to Dojo, but when you say we believe “other toolkits are not optimal for true applications in the browser”, I think you’re missing the mark of the philosophy behind Cappuccino.

    When we set out to build Cappuccino (nearly three years ago) we wanted a framework that was designed specifically and exclusively for building “true applications”. We believe that framework is one that hides the DOM, HTML, and CSS, in favor of higher level abstractions, and a more traditional application development environment. It’s not that these are bad technologies, but they were designed for laying out static documents, not interactive applications. On top of this, by making certain assumptions, and focusing on application level problems (not display level ones), we get to build in features like a full fledged document architecture and rich object based copy paste.

    Just as you can build anything without a framework at all, you can certainly build anything with Dojo too. I’m also sure its much easier with Dojo than without it. But, as your making clear in this post, Dojo is trying to fulfill the needs of the most simple dynamic page to the most complex web application. This may be an admirable goal, but we prefer an environment designed just for the task we’re interested in, building “desktop-class” applications in the browser. I think going forward, there will be room for both approaches at various levels of web development.

    -Ross

  • Henry P

    Pretty interesting, but there was no mention of Ext JS, Backbase, SmartClient? Dojo continues to ignores them, but they continue to gain a rather large market share. Is Ext JS not considered a competitor?

  • ttrenka

    Hi Henry,

    None of those projects are truly Open Source (i.e. freely distributed, liberal license, not controlled by a single entity), which is why Dylan didn’t mention them as competitors. The first two are great toolkits that definitely overlap with Dijit, I can’t speak to the third (I’m sorry, I don’t know that one).

  • phusick

    Great post. I have been with Dojo since version 0.3 and finally I do not have to argue with all those “jQuery Ajax Experts”, who can change the color of DOM element and write some XHRs in functions;)

    To tell the truth, I cannot imagine how anyone can write maintainable javascript code without a package system.

  • @Ross, I’m confused. it seems like you’re objecting to Dylan’s points about projects like Cappuccino, and then saying it’s exactly why they were created, even comparing developing with Dojo to developing with nothing.

    It’s reductive to say that Dojo is trying to “fulfill the needs of the most simple dynamic page to the most complex web application”. While the statement is true, fulfilling those needs is done by two different pieces of code. In fact, your emphasis on frameworks only helps make this next point. The most simple dynamic page is likely built using our main code base, which is the Dojo Base, to do node lookup, basic Ajax, and some DOM manipulation. But when we get into large web applications, you use the parts of the Dojo Toolkit that leverage the aspects of frameworks that you’ve just highlighted above.

    The Dijit widget system is a framework designed to abstract out DOM, HTML, and CSS. It presents to you an object representative of a component. Interacting with such an object requires no knowledge of its underlying DOM, HTML, and CSS.

    Above and beyond that, tools are included outside of Dojo Base to provide abstractions for a host of interactions. We have a data interaction API, an RPC handler, advanced event systems, a full-blown templating system, and the list goes on.

    The argument to be made from projects like Cappuccino should be that flexibility is bad, not that the “lesser” toolkits lack frameworks or tools. The Dojo Toolkit offers building blocks, and projects like Cappuccino offer an environment. It’s unfair to say that projects like Cappuccino are more suited to building a real application, they are just more suited to building an application in a certain way.

    Cal Henderson gave a hilarious keynote at the latest DjangoCon. At 18:20, he talks about developing code with a framework, and notes that frameworks make it amazingly easy and fast to put together an application, but we almost always hit a wall where we need to go outside of the framework. The frameworks within the Dojo Toolkit have been written to impose as few constraints as possible while providing as much leverage as possible. As Cal says, “fast, easy, scalable, flexible, pick two or three at once. You can’t necessarily have all of this in one thing.”

  • Pingback: Ajaxian » Debunking Dojo Myths()

  • Priit

    I wrote an application in late 2006 which heavily used Dojo 0.4 and failed miserably. Later on, i found upgrading to next versions to be too complex and too much effort. Fortunately i had a chance to leave company and have a fresh start.

    I sure believe that today, these assumptions are just plain myths but personally, it will take a long time before i dare to look at Dojo again. It’s just my “childhood’s trauma” :)

    But it is nice to see that Dojo struggled out of these problems it had in early days.

  • gstoert

    there is a spelling is mistake in “Dojo is Ugly”:
    “sense sense of style”

  • Bernd

    Hi Dylan, totally agree with most of your statements – I love Dojo, and do even more so the closer I get to know it.

    But, and that’s the “undocumented” myth part: getting to know it is a hard struggle due to the imbalance between the complexity of the project and the scarcity of the documentation (and I have the three Dojo books sitting on my desk right here – neither one really being satisfactory). The API docs names the methods and properties, but I find that helpful only if I already know that particular method. The DojoCampus docs are a nice approach, but they also lack the necessary depth, the Book of Dojo and its many versions are confusing, inaccurate and point to deprecated methods etc., while it still is the most descriptive resource to me. Search is weak in all of these resources, so with two open books in front of me, and about 6 different website tabs regarding one particular dijit problem I have, I end up finding the solution in a users comment in some forum post.

    Now I know criticizing an Open Source project is generally frowned upon, because, as you say, we can all help. But how can I help when I’m struggling in understanding how this d*** thing works? At this point, I’ve progressed beyond the basics, but still it’s too much guesswork to feel confident in leveraging the dojo project.

  • Jayant

    @Les: If you are going to try Dojo+OpenLayers, why not just try ESRI’s ArcGIS JavaScript API (http://resources.esri.com/arcgisserver/apis/javascript/arcgis/index.cfm?fa=home), its built on Dojo and its just another namespace with Maps & Layers, just like Dojo. Also you can see a screenshot in this very post.

    We have been working with Dojo for nearly 2 years now and are very happy with Dojo and the people who back it.

  • Pingback: Uxebu.com - JavaScript addicts » What dojo really is()

  • Pingback: Dojo Javascript Opinions? - Irish SEO, Marketing & Webmaster Discussion()

  • B.A.S.

    I have done google searches for “dojo table” and “dojo grid” and found nothing but crap.

    I could be catagorized as an old school client server application developer (with 10+ years experience), and realy want to know: does Dojo have a great table widget?; Can table be sorted on multiple colums?; where the heck are examples of connecting a Dojo table with an open source database like MySQL?; Does the Dojo table have hooks for asyncronous updates.

    I found nothing. There does not appear to be anything. If there was some Dojo table widget, would I have include their entire library. Who the heck knows!!!

    I would answer YES to:

    * Dojo is Undocumented
    * Dojo is Just About (funky fade) Widgets
    * Interest in Dojo is Waning
    * Dojo is Ugly :-)

  • B.A.S:

    The best Dojo grid resources available today are:

    http://www.sitepen.com/blog/category/dojo-grid/ (especially http://www.sitepen.com/blog/2008/07/14/dojo-12-grid/ and
    http://www.sitepen.com/blog/2008/10/22/new-features-in-dojo-grid-12/ )
    http://docs.dojocampus.org/dojox/grid

    Multiple column sorting is not currently supported.

    Dojo Grid 1.2 uses dojo.data datastores, making it easy to connect to your MySQL table. If you use or create a store that supports async updates, then you get this for free. I recommend this example: http://persevere.sitepen.com:9080/jsclient/dojox/grid/tests/test_dojo_data_model_persevere.html showing the Grid with the PersevereStore which supports live async updates.

    Your questions do point out a good use case that is lacking a tutorial. We’ll fix that asap.

  • Mike Jasnowski

    I’ve been using DOJO 0.4 days on the BEA WebLogic Operations Control Console (now Oracle) for over a year w/no problem.

  • Micah

    On the documentation question, I would never say that there are “no” docs for dojo. I would, however, say that finding what I need to know in jQuery has been much, MUCH easier than with dojo, largely because of the excellent visualjquery.com. (And have the O’Reilly book for Dojo, but nothing for jQuery.)

    Part of the problem seems to be that there are too many disparate places to go (sitepen, dojocampus, dojotoolkit), so it’s hard to know which are the cannonical ones. Also, the dojo drupal site is pretty damned slow. And finally, Google searches for “dojo ” are pretty likely to turn up stuff from old mailing lists that probably refers to outdated versions, etc.

    There’s some nice stuff in dojo, but so far I’m much happier with jQuery. (I’m in a similar place on the learning curves, working with each in a different project.)

  • “Custom attributes have always been valid HTML, they just don’t validate when tested against a DTD.”

    My claim: Valid (X)HTML is the first step towards cross-browser websites and web applications.

    If the DOM tree is not consistent across browsers, how can we expect CSS and Javascript to behave consistent?

    Could you please show us a link to the HTML 4.01 and XHTML 1.0 recommendations where it says that?

    I have abandoned Dojo, because of the need of invalid HTML attributes. For validation I use this Firefox extension, that validated all pages I browse:
    http://users.skynet.be/mgueury/mozilla/

    I want no errors or warnings on all my pages!

  • @Bo: Custom attributes are completely optional and you can use Dojo without them. Take a look at http://higginsforpresident.net/2008/08/dojo-degradability/ , or even take a look at our own contact form: http://www.sitepen.com/contact/ . Many people in the Dojo community personally choose not to care because it just works and is easy.

    As far as the specification goes, the spec says that browsers are encouraged to just ignore attributes, which all browsers do, and all browsers provide access to them through the DOM. I can look this up for you at a later time, if you aren’t able to find this information.

  • @Dylan

    On http://www.sitepen.com/contact/ you use XHTML 1.0 strict (My personal favorite).
    The Dojo attribute djConfig should be in a dojo namespace like this example:

    <html xmlns:dojo=”…” …

    <script type=”text/javascript” dojo:config=”…” …

    That would be compliance for XHTML, but not reusable in HTML 4.

    I don’t think the validators like the namespaced solution, but they could be fixed by validating only the namespaces they know.

  • I was a loyal Dojo user since 0.4 but not so much now. The overhead cost is a bit too high for really quick prototyping (same is true with other comprehensive libraries though). And the documentation hasn’t been very satisfactory. I learned to use jQuery almost instantly yet was very “clumsy” when trying to pick up Dojo 1.x. It is true JavaScript code is always open source and you can see what functions do by looking into the code, but it’s not very “FRIENDLY”.

  • Pingback: DojoCampus » Blog Archive » Tooltips from Anchors()

  • Nicholas

    @Bernd

    I feel your pain..

    I spent three extremely frustrating days trying to understand how to use Dijit programmatically. I gave up in the end and ordered three Dojo books (I hope they will help).

    Maybe it’s a business model? Write a really amazing framework, get people hooked on it before they realize that its API documentation is terrible, and then sell them books and support contracts?

  • @Nicholas: that’s unfair, it’s not the business model. SitePen builds apps and helps people build apps. Our contributions to Dojo are a result of that work.

    People that contribute to Dojo are historically much better at writing code than docs. The Dojo Toolkit is working on improving docs in a significant way… and the books are good. That said, you can always hop on IRC and ask for help, or go to the forums and ask questions. If there are things that are not documented well, let us know. And yes, we do offer paid support and training services, but that’s generally used for more advanced topics.

  • Pingback: Framework-uri JavaScript: Introducere | Interfete Web()

  • Tubal Martin

    @Bernd & Nicholas: Same here. I feel your pain.

    For me Dojo is the best javascript library out there, hands down.

    I’ve used it succesfully in several projects (RIAs), but I’ve always felt the need for a more exhaustive/deep and up-to-date official online documentation. We need it guys, seriously.

    I also have 2 of the Dojo books (O’reilly’s & Pragmatic’s), if I didn’t have them…who knows…maybe I’d have already switched to YUI.

    Apart from developing RIAs and sites, I also give Javascript/Ajax courses (I enjoy teaching) and when I talk about the main libraries, students ask which the best one is. I find really hard to answer that question becuase I have mixed feelings.

    As a programmer, I know the best one is Dojo. However, its poor/superficial documentation makes me recommend either the YUI toolkit (similar to Dojo in features & modularity) or jQuery.

    Most students take the jQuery path and I understand them; easy to learn, their online doc is great and enough, a huge active community behind, many non-programmers using it (designers) and the fact that most sites and apps won’t require any widget Dojo or YUI provide (if they ever need one, they’ll use a plugin) makes jQuery their choice.

    My suggestion to Dojo developers: Better online documentation will return many more developers using, loving and supporting Dojo.

  • @Tubal: I’m curious to get your feedback on the work being done at http://docs.dojocampus.org/ . Is this superficial or getting there in your opinion? Also, what do you think of the value of content such as that found at http://dev.opera.com/articles/view/introducing-the-dojo-toolkit/ ? I’m trying to gather as much useful feedback as possible so that I know what our most important priorities are to fix first with regards to docs.

  • Tubal Martin

    @Dylan: I think the work being done at docs.dojocampus.org is getting there (a lot to be done yet) and the article at Opera’s dev center is a nice one.

    My suggestions about docs:

    1. All documentation hosted and accessible from dojotoolkit.org:

    Spreading docs over different sites is confusing for new comers and a lil’ bit annoying for “veterans” and I would choose Dojo’s home to host them to keep everything in one same natural place.

    2. One manual/reference to rule them all:

    In http://dojotoolkit.org/docs there are right now 2 dojo manuals or reference guides; 1.0 (hosted at dojotoolkit.org) and 1.3 (hosted at dojocampus.org).
    Both stand for dojo version 0.9 and up…the issue is, choose ONE to feed.

    3. Supported/Available from Dojo version x.x.x

    This suggestion applies to all docs and API reference.
    If a method or module is only supported, implemented differently and/or behaves differently from a concrete Dojo build version just let the user know at a glance. No need for n dojo guides or n dojo API version tabs.
    I’ll design some mockups if you’re interested.

    4. Dojo version running examples and tutorials:

    At dojocampus.org, dojotoolkit.org or wherever you publish a tutorial or a demo, let the user know at a glance which version of dojo was used.
    It would be even better if the user could know at a glance from which Dojo version the published demo or tutorial works exactly as it does with the actual version used.

    My best wishes!!

  • Pete Schwamb

    I’ve recently started using dojo, and will reiterate what others have said about dojo documentation. This has been a huge stumbling block for me; trying to find my way around multiple sites, and not knowing what dojo version is being used when looking at examples have been some key trouble points.

    That said, I’m still pretty impressed with dojo, coming from prototype.js. Thanks for the great work!

  • Tubal Martin

    A couple of additional suggestions:

    5) From now on, never release a new Dojo module or method until you have its documentation ready to be published.

    6) Classify Dojo reference guide contents by functionality:

    This suggestion applies mainly to the Dojo 1.3 reference guide at http://docs.dojocampus.org.
    Instead of listing alphabetically every module in Dojo with a short description, classify them by the functionality they provide (semantic context).

    Examples of main categories:

    Core (Utilities & helper methods)
    DOM Traversal & Manipulation
    Events
    Server Communication (AJAX, cometd, iframe, script, RPC & dojox.data API)
    Animations & Effects
    Widgets (dijit and dojox widgets)
    Cookies
    History/Back Button
    Internationalization
    Accesibility
    Cryptography
    Offline world (Gears, storage)
    Extending Dojo

    Many like Dojo and use it but many, many more like Dojo but don’t use it, that’s the key issue.

    There’s no other Js framework as powerful and complete as Dojo but documentation is Dojo’s Aquilles’ heel.

  • Pingback: MooTools vs JQuery vs Prototype vs YUI vs Dojo Comparison Revised | Peter Velichkov's Blog()

  • Dave Johnson

    I am new not only to Dojo, but also to HTML, CSS, Javascript and all the rest. Thus, I cannot comment on the technical merits of the library, much less in comparison to other toolkits. However, I do have more than 30 years of development experience – going all the way back to Fortran and keypunch machines – and I also have a whole lot of experience reading other people’s code. Thus, I don’t find Dojo too difficult to penetrate in general, but I do think there is one way the documentation could be improved for newcomers. Namely,it would be useful to see a description of how a Dojo-based page loads, gets parsed, etc. I would also include some background detail about how the browser in general loads a page, applies style sheets, invokes the Javascript interpreter, and so forth. Perhaps this is all obvious to those with loads of web development experience, but it would be very useful to see an overview of how the toolkit fits into the language environment, and how the language in turn fits into the overall browser operating environment. As I say, I have decades of practice sorting out things like this for myself, but if you want Dojo to be a market leader, you really should work on creating a very, very smooth path for newcomers. After all, when MS Visual Basic came out no one thought it was a very serious language, but it was so easy to build things with it that it was soon wildly popular, even with the limitations it had back then. No messing with the event dispatch loop, no writing code to put everything on the screen. Just drag and drop to design the forms, and then attach event handling code to standard hooks with obvious names. In this spirit I took a look at Wavemaker and SmartClient, but no joy there. It looks easier to use Dojo directly, at least for the moment, so I’ll deal with it. However, a good drag and drop page designer coupled with a good architecture manual would be very attractive. So, maybe the Dojo group could move on to making their own design tools, as well as adding some internals documentation. Thanks. Sorry to be a bit verbose.

  • Paul Snyder

    I have found the documentation to be less than adequate. I needed to get a grid up and running, but found nothing that explained that it is crucial to set the height attribute or the grid will mysteriously not display. HOURS!@%&! It seems to me that there is a mysterious dependency that dojo objects have on css — a dependency that the initiated seem to take for granted when documenting how to use their widgets. Every dependency should be explained in the tutorial material, or people will change a class attribute and suddenly the damn thing doesn’t work anymore, and who would have thought it???

  • Hi Dylan,

    As others have commented before me I must say that even though there are _alot_ of documentation it is terribly, terribly bad. The Dojotoolkit sounds very promising but without good documentation it could be Gods gift to mankind and I, and apparently many others, still wouldn’t use it.

    Why is the documentation spread out all over the place like that? Why not include sample code in the API docs? Look at the PHP documentation. They did it the right way. Simple, concise and with user commenting. I think that the great docs over at php.net is a major factor to why php is as big it is today.

  • Thanks everyone for the feedback… we’re obviously working to make the documentation better and appreciate your suggestions. Dojo is obviously a volunteer organization, so if you would like to get more actively involved in making this better, please let me know. Regardless, substantial progress is being made to make this simpler and better.

  • Brett B.

    I’m a newb to JavaScript and consequently Dojo, but I am growing more familiar with it every day. Once I was acquainted with the basics, things became very simple in Dojo and I was able to do more with less. I like that.

    I want to know more and do more with Dojo.

  • Rick O’Shay

    Myth #1 Dojo is Undocumented

    It’s useful to consider what drives this myth because there is indeed a mountain of documentation. The problem is it’s utterly horrific.

    Take a look at the API and tell me whether you see something other than regurgitating the name of the method and its arguments. There’s no type information for the parameters or return type, for the most part. There are also no examples. The forums are generally non-responsive.

    A WORSE problem is that significant changes to the API result in a confusing pile of useless noise in trying to use the latest. I see there is a new documentation effort on the “campus”, why don’t you UPDATE the existing dojotookit.org documents?

    Let’s summarize: Dojo team is in denile and refuses to acknowledge what a steaming pile the documentation is with respect to typical APIs.

  • Rick O’Shay

    Myth: Dojo is Ugly

    This is truly a myth. Dojo looks quite professional. The problem is you are essentially stuck with the themes provided. Don’t think so? Then explain the almost total lack of additional themes.

    If this was done correctly there would be a theme document or better yet a theme tool. The idea that you are going to hack in custom CSS and hope there are no negative ramifications is great for those with nothing better to do and an unlimited budget.

    This is another case of Dojo denial. Where is the theme generator? Where is the theme document that specifies precisely how to create a new custom theme. Again, that there are only a handful of themes belies the notion that custom themes are even remotely practical.

  • Michael Sharman

    Without an understanding of how CSS or HTML works, I can see how people would find Dojo difficult, but this is because Dojo works with CSS and HTML rather than abstract away from it.

    I come from a web development background and have spent the time to come to grips with HTML and CSS and find that Dojo doesn’t get in the way of using CSS, in fact it uses CSS extremely well.

    I tend to use Firebug to see what CSS classes are used where when I need to, but as far as I can tell there is no documentation on this, so maybe the comments about making themes have a point.

  • Jacob_A

    @Paul Snyder – I had the same experience, strange unpredicted interactions between CSS and dijit widgets

    @Rick – Strong agreement. Tons of documentation but poor organization, only moderately useful examples, and you forgot one: SLOW DOCUMENTATION SERVERS.

    I have used dojo/dijit for two projects now: one in v0.9 and the second in v.1.3. I have moderate experience writing code in Visual Basic, C, C++, and Java.

    For 0.9 I used the “book of dojo.” I knew nothing about javascript or ajax coming in. I managed to learn on the fly by copy/pasting a lot of code form the book of dojo and the “dijit theme tester” but only partially understood what was going on and why. Finally, after copious amounts of effort, actually managed to get a site up and running in an alpha version, only to discover extensive incompatibilities with IE7 in the dojox.grid widget (we were using FF for development / debug thanks to firebug but IE7-8 support was/is required). Never managed to fix it and the project has been temporarily shelved in favor of a different project after a break. One thing I noticed during this effort was that the book of dojo actually had some thoughts in there about some obscure use cases, I think there was actually one note in the border container content about requiring a height attribute. I don’t remember any such note about the grids. Another thing I noticed was that half the time when I loaded the book of dojo pages, they would hang or the theme wouldn’t load correctly and I would not be able to read the text. Very strange.

    For this second project, we started after the release of dojo 1.3.1 and used the refactored grid widget, things were considerably smoother… but the documentation was still a sore point. We had scrolling behaviors using title panes that were repeatable but completely unexplained, and still to this day we couldn’t fix them. Had to create a workaround.

    I would echo Rick’s comment about a theme generator also. The only theme we’ve ever been able to get to work was tundra; noir and the other one simply won’t load. I would love to easily be able to create my own theme concepts, even if based upon one of those three and then changed a little.

    I think the documentation model is on the right track, and should principally focus on two areas:

    1) Dojo campus appears to be more aimed at newbies with copious examples, user tips, that kind of thing. The main problem is navigation: I frequently end up having to go out to google to find the dojocampus page for a certain dijit widget or dojo function, and still some of the “I don’t know what the heck I’m doing” documentation is a little beyond a n00b audience. Again, though, PLEASE fix the navigation, it shouldn’t be so hard to get around in that site (especially from dojo to dijit to dojox)

    2) The API site. This has a listing of parameters and such, but as Rick correctly pointed out there is little explanation of those parameters, what they affect, correct usage examples, etc. There are a lot of assumptions made regarding contextual understanding which may not be accurate. There is also virtually zero explanation of what’s going on behind the scenes.

    Well, that’s it for now. I need a typing break… :-P

  • Rich

    It’d be useful if http://docs.dojocampus.org/ wasn’t down so often, like right now when I need it!

  • Pingback: Learning Dojo | SitePen Blog()

  • Don’t get me wrong. I love Dojo, I love SitePen for all the work you guys do on it, and thanks. But I hope by now you no longer believe your documentation is good. It seems like various parties have put a lot of work into it, but its worth little. The only useful documentation — and very good, too — is in the source code itself, and that’s all I look at any more — I never do bother with dojocampus, or dojo api. I either google or go directly to the source.

    Here is a PRIME example, from just last month, in the year 2010. The guy’s question is pretty simple: “How do I get the response headers from an XHR?”. Look in the source code, is Eugene’s answer. Lots of back and forth among people with hazy knowledge, before we get to Eugene’s answer. I felt sorry for the OP, and empathize with his POV. But just take “well documented” (outside of source) off your myth list — it’s not a myth.

    http://dojo-toolkit.33424.n3.nabble.com/howto-retrieve-response-headers-td791238.html

  • GGL

    I agree with Hugh, Dojo maybe a great framework/api but with the lousy outdated documentation and no current learning texts to speak of its a ‘special club’ whose members are those who have been using it forever, those who have the time to review the source or those that can trial and error through the issue and produce quality code on time.

    My professional experience with it has been miserable and even though my livelihood depends on learning this junk, I dont think I will ever be successful with it. After 15+ years as a developer, I got a gut feeling that this is developed by those who like to play with all the neat stuff and dont have the discipline to produce a production ready product.

  • tom myer

    Sorry to say, I still agree in 2012 with most of the critics regarding docs… Dojo is neither a full dom abstraction (xyzwidget.domNode is still required many times…) nor as expressive like jquery when manipulating the dom. I´ve to work on a dojo app right now, I find it extremly frustrating for days now… my approach for the future: avoid dojo completely and use either extjs or backbone.js. Sorry guys…

  • Hi Tom,

    Thanks for your feedback.

    The docs have improved significantly with the 55 part tutorial series, the quickly improving reference guide, and the almost complete rework of the API documentation viewer. We’re getting a lot of help and it’s looking far more promising than it was previously.

    Could you explain where you are frustrated? What do you not like, where are you stuck? Have you asked for help on the mailing list or on IRC?

    Regards,
    -Dylan

  • Swapnil Jawale

    Hello, Friends. I have just started working with dojo, so I am not in a situation to say that dojo is good or bad. But I really want to say that there is less documentation available. I am trying to create a Dojo Datagrid programmatically but found nothing which can help me out with my problem and what are the attributes which are given to the constructor of the DataGrid?
    If anyone knows please help me, my eamil is swapnil01jawale@gmail.com

  • Hi @Swapnil, have you looked at http://dojotoolkit.org/reference-guide/1.8/dojox/grid/DataGrid.html and http://dojotoolkit.org/api/1.8/dojox/grid/DataGrid ? Or perhaps you might want to look into using dgrid instead? ( http://dgrid.io/ )

  • Ohgasauraus

    The main problem I have with dojo is their site that have those example and provided a button to test run those example, none of them works for me. I tried using IE, Chrome & Firefox and none of them works… I guess they didn’t bother to check if those example are even working…

  • @Ohgasauraus We did check to see if they are working, but keep in mind that with the reference guide in particular, the problem there is often the demo tool itself, which in hindsight was not a great idea as currently implemented. The idea was to have examples that are both runnable and easy to learn from. The problem there is that this means that the code is unoptimized (so that you can view the raw source), and every resource needs to be loaded dynamically along with its dependencies. This doesn’t match a real world scenario where you would optimize for performance. In general, the code examples work fine, though some are out of date. But most that are failing are because of the tool itself, or take a long time to load if they have a large list of dependencies, which would not be an issue in a production environment, but may lead users to think they are failing when they really just take a while to load many files over the network.