

Dojo for jQuery Developers: A comprehensive tutorial - amitu
http://www.dojomonk.com/2013/05/dojo-for-jquery-developers.html?q

======
HarrietJones
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.

~~~
amitu
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.

------
75lb
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.

~~~
amitu
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.

~~~
75lb
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.

------
knappador
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?

~~~
amitu
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.

~~~
knappador
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.

~~~
amitu
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.

------
Yuioup
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.

~~~
amitu
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.

~~~
Yuioup
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.

~~~
amitu
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.

------
smegel
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.

------
hayksaakian
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.

~~~
amitu
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.

------
ergo14
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.

------
pags
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.

------
amitu
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.

~~~
ebiester
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?

~~~
amitu
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_.

------
etfb
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".

~~~
amitu
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.

------
gyanganesh
Great post! nice learned a new thing:)

~~~
amitu
Thanks to be of use :-)

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

~~~
amitu
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.

~~~
ferz
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.

