While I'd agree that the documentation could really use an overhaul, once you figure out what the "modern" way to use it is - I've found it to be none of the things which you describe it. I recently implemented an application on the 1.6 version of Dojo, and found it pretty easy to set things up using an MVC pattern which, while I could have implemented myself in JQuery, would have taken longer and wouldn't have been built to the standard Dojo expects. Here are a few things I like about it:
* It has a layout manager, so I can build fluid UIs that are divided up into various content panes that react via the MVC model. I tried a few different layout manager options out there under JQuery, and none of them integrated well with other libs I wanted to use.
* It has an event bus built in, which means I can decouple components but allow them to communicate asynchronously.
* It has a wide range of components that I can drop in, rather than writing myself.
* It's component model is actually kind of slick. You can define a view file, which is just some specially marked up HTML, and then a backing code file for it, which acts as the controller / event manager for the file. You can then define classes at the page level that act as controllers to wire up all of your individual components. No generation via strings.
* It has a built in dependency mechanism that dynamically loads only the components you need for a given page. It also has a build system that lets you package up only the components your application actually uses.
Sure, I could hunt around and try and duct-tape each of these pieces together individually with JQuery, but for my use cases, the "batteries included" model worked really, really well.
Yes, there is seemingly a lot of documentation, each part of which describing about 80% of what you need to know. They've put a lot of effort into it, I think, yet it needs more effort. Since I haven't contributed to that effort, I can't complain. My advice: just read the source code. I wish you could just read the docs and understand the semantics of every api, but I finally realized that, if I cannot google the answer to my question in 15 seconds, just open the source code, which is excellently documented (internally), and very consistent in using patterns.
There is also the problem of having the documentation being "split" whenever there is more then one way to do something (say declarative vs programatic widgets) or there has been a major API upgrade (say AMD modules or the ObjectStores) so you also need to learn to convert from one to the other.
* It has a layout manager, so I can build fluid UIs that are divided up into various content panes that react via the MVC model. I tried a few different layout manager options out there under JQuery, and none of them integrated well with other libs I wanted to use.
* It has an event bus built in, which means I can decouple components but allow them to communicate asynchronously.
* It has a wide range of components that I can drop in, rather than writing myself.
* It's component model is actually kind of slick. You can define a view file, which is just some specially marked up HTML, and then a backing code file for it, which acts as the controller / event manager for the file. You can then define classes at the page level that act as controllers to wire up all of your individual components. No generation via strings.
* It has a built in dependency mechanism that dynamically loads only the components you need for a given page. It also has a build system that lets you package up only the components your application actually uses.
Sure, I could hunt around and try and duct-tape each of these pieces together individually with JQuery, but for my use cases, the "batteries included" model worked really, really well.