I could have done with this two months ago.<p>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.<p>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.<p>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.<p>I think this : <a href="https://github.com/rmurphey/dojo-scaffold" rel="nofollow">https://github.com/rmurphey/dojo-scaffold</a> 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.
I just started using Dojo - hate it..<p>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..<p>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 <i>your</i> code, not the other way around.
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.<p>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.<p>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?
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.<p>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 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.<p>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.<p>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.<p>I think the Ajax model works pretty well, although the whole promises/futures took a bit to get used to.<p>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.<p>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.<p>All I expect from jquery is Dom manipulation thats consistent among browsers.<p>I applaud competition, but Dojo is not for me.
Highly recommended :]<p>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 <i>massive</i> 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.<p>For a new project, give dojo 1.9 a try.
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".