Dojo for jQuery Developers: A comprehensive tutorial | Hacker News Reader

Dojo for jQuery Developers: A comprehensive tutorial

dojomonk.com

40 pointsamitu34 comments

I could have done with this two months ago.

I've just finished quite a large dojo project, and it has been a huge pain in the ass. It is impossible to debug, the AMD changes are confusing as all hell & it is badly documented, but its biggest flaw is that it has a hockey stick learning curve. You can get to jQuery mastery in your own time, but for you to produce anything decent with dojo requires you put a whole heap of unuseful headscratching in at the start.

If you're a great programmer, then maybe dojo is for you. But if you're an average programmer who needs a degree of discoverability in the tools that they use, then I would steer clear.

Another problem is that the framework is currently in a half-finished state (mvc anyone) and it looks like it's going to stay that way for a while.

I think this : https://github.com/rmurphey/dojo-scaffold was posted a while ago, but if you haven't seen it - then it might be worth looking at. Again, I haven't used it, but if I had known about it before starting a dojo project, I would have given it more attention.

In my opinion you need dojo-scaffold (now outdated) or dojo-boilerplate(still recommended by dojo developers) only if you do not understand dojo well. I am quite sure after reading the article I wrote you will not need any of those clutches, and do things the way you please.

Dojo's learning curve is a big problem, and I am trying to do my bit to address that.

The changes are confusing, yes, but what can you do? You can not live with old just to not make things confusing.

I believe the great programmer bit is only another way of saying the documentations are lacking, and not that dojo itself is more "complex" than jquery (of course it does much more, so compare it with jquery+requirejs+backbone+<there is no widget library in jquery i believe>).

Debugging is a pain in the ass, yes. I am not sure what is the answer to that.

I am planning to do a few more articles, covering MVC etc in a little bit more detail.

To me the first question is technology, dojo represents a solid, well thought out technology, secondary is documentation/learning. I would be willing to spend an extra week to learn something with sparse/confusing documentation, if it provides me with an edge when it comes to future work. And in my opinion dojo does.

I just started using Dojo - hate it..

but in general, i'm beginning to despise monolithic "do everything" toolkits/frameworks like Rails, Meteor and Dojo - the level of "vendor lock-in" is hellish..

just stick to plain old HTML5, OO Javascript and simple, specialised libraries which can be mixed in as and where required.. make the libraries depend on your code, not the other way around.

There is no "vendor lock-in". If you read the article I have written, if you have written AMDs you can use requirejs.

What I highly recommend if use dojo's declare way of doing object oriented javascript.

Specialized libraries are always going to beat general purpose libraries, but the reason big frameworks are popular is because they give a structure to the project. The dojo project I did will look quite similar and familiar to any other dojo developers, we will use same way to build our builds, same way to represent data using object stores, our classes will be compatible with each other, and our widgets will look familiar.

There is value in it.

i agree there is value in developers sharing the same architecture and conventions, but that's a general truth.. don't need Dojo for that.

> "and simple, specialised libraries which can be mixed in as and where required"

Well if you're using the AMD syntax, that's what you're doing, albeit initially limited to the (extensive) dojo library.

I personally find the dojo core relatively simple to use. Each individual module is small enough to grok in a few minutes.

To be perfectly honest, the API changes from 1.7 to 1.8 were pretty much catastrophic. Might as well have included instructions on bandaging back lacerations. It was like working with a different library. JQuery looks good to go for another 20 years. It's easy so it costs me no effort to maintain the skill. If it eventually dies, I will have moved on to native pastures already.

The arguments about being able to do all kinds of crazy stuff without bloating code size just don't make me happy at all. Should we include an extra build step and production pipeline complexity for web, something that is supposed to have flexibility and speed-to-deployment as its evolutionary strengths? I can't even remember how much time I ended up spending on JUST the silly require boilerplate, which accomplishes mostly nothing because it's not like I ever want to fetch javascript asynchronously. CDN JQuery is a 304-not-modified and my code is gzipped by nginx if the page is over 4kb. Hey look, it's really fast and I didn't work at it.

JQuery 2.0 is about to be out, so goodbye old IE bloat. I'm happy with ever increasing internet speeds, ever faster browsers, and a plethora of small libraries ideally suited for various legs of the journey. I've never used underscore, knockout, or angular, but I know that if I ever run into a problem that requires more architecture, I should go find out what they do. This can be one's approach towards almost all problems in web. Which comes first: a focused javascript library or an implementation of it on top of the Dojo (or any other) API?

My opinion is that dojo should forget about backward compatibility once, or create a dojo2 fork, there is too much new things happening that are quite exciting. But dojo is slowed down due to legacy code support.

jQuery is good for another 20 years. But is backbone? or angular? or Would it be the new components thing google released?

Remember dojo is not just jquery, its jquery+backbone+requirejs and few things put together.

I really did have some hope for being able to use some of the DB-like tools and integrations with Django, and even started work on using the graphics library to write an SVG converter to display on all browsers. What a dead end all that turned out to be. Libraries like lawnchair, history, and kinetic or some other canvas library just seem to run circles around the larger libs for whatever it is that the focused libs do.

I really like larger web frameworks like Django because a lot of what those frameworks provide is only won at a high-cost to the programmer if not done as part of the architecture. Going more micro means more work in those cases. Going more macro with JS when 99% of pages need a contact form is not making me feel empowered.

JS libraries are to me like single-celled organisms. Sure they spring up and die a lot, but out of all that change and natural pressure to remain small and decoupled, it's not necessary to tie one's future to any one of them if they act up. Dojo 1.8ish made me greatly loathe not being able to swap out that one misbehaving part because of commitment to the larger scheme.

I take your point. Dojo has tried to do a lot of things, and some of those have not panned out as well as the other parts.

I am getting your point. I would prefer if dojo lowered the marketing on the rich set of existing widgets, as very few people will every use dijit/Button over native button.

But dojo's object store/MVC, dojo's widget system itself, the build system/AMD, they have proven themselves over a period of time.

Don't use dijit widgets, but do create widgets using dijit/_WidgetBase is my recommendation to everyone learning dojo. And none of the grids, and layouts and SVG etc etc. They inclusion in dojo code base is one of the reasons so many developers get put off by dojo.

Please take a look at the application I have built, the build step is just two commands: https://github.com/amitu/dkudos/blob/master/build_dojo, and the "require boilerplate" is just 7-8 lines: https://github.com/amitu/dkudos/blob/master/prof.js (if you ignore the comments).

A lot is happening in dojo, the dojo development has picked up pace lately and dojo2.0 is going to be a huge step forward for simplicity and richness.

I have mentioned at the beginning, if you just want a jquery like work, Google's CDN is available for dojo too, and the CDN has all the modules required to get jquery level functionality baked in.

IIRC HTML templates never quite let me auto-detect what JS to include in the builds. The manual configuration was too much of a pain. That 7-8 line file is sitting there saying RTFM for something that is trivial when taking the path of least resistance. Copying a one-liner to load jQuery into a base template is as simple as it will get.

I'm basically resistant to any and all JS compilation. It's like multi-threading in pure Python. It's more complex, doesn't leverage the existing strengths, and in the end doesn't even really do what it says it does.

If you do not do JS compilation then you are either forced to not split up your project into logically different files, or you incur too many HTTP requests over head.

If a project is just a few lines copy pasted here and there, then sure, but for any more complex project you have to build.

Dojo tries so hard to turn JavaScript into a full-fledged OO framework. The problem is that Dojo is not intuitive at all. Most of the time you get lost in the forest of angle brackets, DOM (dojo?) nodes, delegate functions, etc. It's impossible to debug. On top of that the documentation is awful.

Dojo will unnecessarily increase the development time of your application to a factor of 4. My recommendation is to avoid it at all costs.

I have written the article because I agree with you, dojo is not intuitive. Dojo has a lot of documentation, but since dojo is in such a flux there is a lot of documentation that is out of date.

After using dojo for at least one big project I am have a different experience. For the first time I started thinking about software engineering principles when I used dojo in client side. All my previous projects were in jquery and while they work, jquery has not helped me one bit in managing complexity.

I have written my experience about how to use dojo right. Do not use too much of dojo, don't use dojo for page layout, do not use dijits that may not be as well tested as the core.

I would highly recommend you give the tutorial a try.

I think that's the problem. Because it is so much in flux one minute you think you have the framework down and the next minute you realize that things have changed.

It's interesting you mention complexity. When you're developing a very rich client-side complex system, at what point do you stop and realize "maybe I'm taking this too far"? I'm beginning to notice that people are developing web applications the same way we did when we were writing desktop applications about 15 years ago. I personally think that we should absolutely not be trying to rewrite desktop applications for the web.

Once the web application gets so complex that you need to reach for Dojo is when I think the application should be rethought and rewritten from scratch.

True, but it is not like dojo is continue to do that. Dojo is going to a 2.0 release and there is a massive change between 1.0 and 2.0, primarily AMD. Dojo has previously shown a long history of backward compatibility. One of concerns of many dojo developers is that they should abandon the old code and directly switch to new one as the transition period is not doing any good to new developers trying to learn dojo, but if you have already written an app, dojo provides excellent backward compatibility.

Weirdly, I have the complete opposite experience with dojo.

The streamlined AMD loading makes it really easy to write modularized, structured projects and build it into release bundles. The store concept and compliant widgets are excellent, and while admittedly much of the dojox stuff is fragile, the dijits in general are very well made. The charting and drawing modules, with fallbacks (SVG, canvas, VML, Silverlight) have also been great to work with in my experience.

Can you give some examples of things you find unintuitive or confusing? What makes it more difficult to debug than other Javascript libraries? How do you find the documentation lacking? (The latter has become quite a bit better in recent years, you may want to look at it again if you haven't in a while).

I can understand that dojo may seem daunting at first. After all, something as simple as

  $('#foo').html('<div>foo</div>').css(...).click(function(....

in jquery, takes a fair bit more effort in dojo. This, and I suspect, quite a few of the other grievances you have, stem from dojo's insistence on modularization. This seems unnecessary at first, but in my experience, pays off as your code base grows.

My recommendation is to seriously consider it for any complex javascript application.

I quite like dojo. As a total non-Web developer, who nonetheless is forced to put together internal web apps from time to time, dojo just seems to get the job done.

I use dojo layouts a lot, as i could not code the necessary css in a million years. Yes it cheats and uses Javascript to resize components, something that apparently makes Web purists cry, but for me it was just another quick solution that worked.

Similarly dojo 2d charts -- there may be better solutions out there, but with dojo they are built in and just work for the most part.

I think the Ajax model works pretty well, although the whole promises/futures took a bit to get used to.

There its definitely a learning curve, and if i just wanted a bit of dom manipulation i would probably still just use jquery-- but i found dojo to be invaluable when it came to developing more complex client side apps that could make use of a batteries included framework.

Things i didn't like - a lot of the documentation seemed to relate to a prior version (i started with 1.8 i think), so finding the appropriate way to do something could take a bit of work. Also debugging was often difficult, as the error was often raised in some anonymous function created deep within dojo. Sometimes the stack traces were useful, sometimes not.

I gave it a shot, but it seems like dojo is trying to do too much.

All I expect from jquery is Dom manipulation thats consistent among browsers.

I applaud competition, but Dojo is not for me.

Like I mentioned in tutorial and in the other comment, we are doing too much today. With advent of HTML5 we are pushing more and more server logic to client. Today we have javascript templating languages, javascript MVC frameworks, all of them to address the new reality that today web clients do lot more than just manipulate DOM.

Going forward client is only going to get more and more rich, and dojo has a cohesive and consistent solution for handing these "rich" aspects.

If all you need is DOM manipulation then it probably doesn't matter what you use. Heck, with jQuery dropping IE support, if you only need DOM manipulation then why are you even using jQuery?

Dojo has been great for managing our very complex UI - I certainly wouldn't want to do it in jQuery, but that said, I wouldn't necessarily choose dojo for some brochureware website job.

In other words: the right tool for the job.

Highly recommended :]

It's a good read especially for developers who want to do cross-platform mobile apps with phonegap and such. All this knowledge applies there.

I get the sense from reading some of these comments that most people who try Dojo don't really have a clear understanding of what it is, or how to separate and leverage the individual tools that it provides. Too bad, since it's a really powerful toolkit. I'd suggest anyone looking for MVC structure to not neglect looking at Dijit templated widgets.

Please guys, ignore the dojo history. There is massive difference between dojo 1.6 and 1.7, and 1.9 is much more improved version of 1.7 too. Dojo is changing fast, do not dismiss dojo1.9 because you burnt your fingers with dojo1.3 or due to migrations.

For a new project, give dojo 1.9 a try.

So, is there gong to be another massive difference between 1.9 and the next version where I'm going to have to relearn everything again?

Dojo is trying to get rid of the design elements present since as early as 2005. In another decade yes, but this whole shift to is geared towards a more stable 2.0. It is the developers who want more change, not the dojo foundation, who is more focused on backward foundation.

And changing the way you access a method (from global variable to requiring them through AMD) is not relearning everything.

Nice, but he needs to change the name. Kudos isn't a plural noun. There's no such thing as "a kudo" or "several kudos". It's like saying "I had a computer in the 1990s that had an MS-DO on it, but I upgraded it with a couple of DR-DOS I had lying around".

Hey, it was just a tutorial feature, I have tried to faithfully copy the feature as done in jquery to demonstrate its not really any different from jquery, and if you read till near the end, its arguably much better than jquery based solution. Of course you can use MVC/AMD etc with jQuery, but it will send you in search of a new solution, unlike dojo which has it covered, rather nicely.

Great post! nice learned a new thing:)

Thanks to be of use :-)

Appreciate Dojo for it's history - but do not use it for your next large-scale JavaScript project.

I am here saying you must consider it for next, especially large scale javascript project. Start with dojo-1.9, assume anything before this never happened. Read my tutorial. I dont want to be contradictory, but dojo truly shines in large scale javascript project, where jquery has no help, unless you use something else.

Dear Amitu,

many jQuery users don't want to improve, they want to believe into theirselves knowledge.

In my experience many of jQuery fans don't care about large client side apps, most of them are graphic designers not developers: they can cut-and-paste code but they are not able to write more than 25 lines of source code and understanding what they are doing.

I appreciate your article, thank you.

Reply on news.ycombinator.com