But, I wish Dojo was still a bit more straightforward to package up the various modules/widgets our project is using into a single .js file. For now the dynamic parsing with dojo.require works fine. But as the project grows it won't cut it anymore.
Congrats to the team :) (PS. When can we expect it to be available through the Googel CDN?)
Perhaps I'm too spoiled by jQuery UI Builder. I'd much rather prefer something like this where I can just pick the widgets I know I'm using: http://jqueryui.com/download
Does anyone actually think dojo has a future compared to the power that jquery gives to make your own "widgets" but far simpler than dojo?
The simplest tutorials in the dojo documentation put html tags in the JavaScript code. Generating them like strings. It reminds me of the days when people would generate html (and javascript, oh god) using Java.
Dojo is too big, too complicated and bloated. It should be split up/down in all its major components.
It really depends on what you're trying to do, I suspect. I'm on the jQuery core team and it's nice to have a lot of people building off our work.
> The simplest tutorials in the dojo documentation put html tags in the JavaScript code. Generating them like strings.
Yes, simple documentation examples often have HTML in them, the jQuery docs do it too at times. It's a lot harder to build real examples without all the extra stuff getting in the way of the simple concept you're trying to demonstrate.
Go into your browser's debugger and look at how many apps (including jQuery-based ones) are written. They use MVC frameworks but then create big chunks of HTML in JavaScript to generate the views rather than using templates. Here's one for example, from a very large newspaper site: http://i.imgur.com/a4R6I.png
Are you saying that jQuery is to blame for this app using embedded HTML, since we sometimes use it in our demonstrations for the docs?
> Dojo is too big, too complicated and bloated. It should be split up/down in all its major components.
Waitaminit, I thought jQuery was too complicated and bloated, at least that's what several people here were telling me when I posted the announcement here about jQuery 1.7 being released.
Most likely a big app needs darn near every byte of the base library it includes. Go over and look at the Mootools configurable download builder and tell me which of those checkboxes you could leave empty on a big project. Many of these big apps are more than half a megabyte of minified code. All of jQuery is about 92KB and Dojo is 100KB. I have seen the other 400+KB, and it is the problem.
Just like programming languages, libraries can be used improperly. Don't blame the library for the people who misuse it.
Specifically dojo has this useless dijit widget collection. For any serious web app I doubt you would find dijit suitable to exactly your needs. Which means you have to develop your own using the query/animation/events api.
* 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.
If what you have to do is manipulate the DOM and do XMLHttpRequests, then jQuery is more than good enough, otherwise Dojo has a lot to offer.
Some features from Dojo which are not about DOM manipulation or XMLHttpRequests that I use a lot:
- AMD-style modules (you can have this with jQuery, but Dojo is built with AMD from the ground up) http://livedocs.dojotoolkit.org/loader/amd
- the build system http://livedocs.dojotoolkit.org/build/index
- object stores http://livedocs.dojotoolkit.org/dojo/index#store-dojo-store
- deferreds (jQuery has these now) http://livedocs.dojotoolkit.org/dojo/Deferred
- templated widget definitions http://livedocs.dojotoolkit.org/dijit/_TemplatedMixin
- publish/subscribe http://livedocs.dojotoolkit.org/dojo/publish
- observable attributes http://livedocs.dojotoolkit.org/dojo/Stateful
This doesn't mean that you should be using it, just use what feels better for you. For some people (like me), Dojo is what feels better.
I always use jQuery myself, but I'm still not satisfied with any of the jQuery grid components, for example. It's disappointing.
Not that jQuery doesn't have any of these. But jQuery was thought out as a DOM manipulation library and then people started sticking a ton of things on top of it.
Dojo is thought out as a modular toolkit, where DOM manipulation is just one of the libraries it includes.
But it doesn't sound like you've actually used Dojo. It's neither big, complicated or bloated. Things ARE modularized, and the core has a lot of bits that are useful outside a browser environment. If you look at jQuery, the whole thing targets being run in a browser. Dojo base has a lot of language utilities that are helpful - say if you're using it in node.
Also the idea of "dojoAttachPoint" as an attribute on basically any tag is questionable. If I recall only the latest html spec allows that, but dojo used it even before.
