Dojo Toolkit 1.7 Released.(dojotoolkit.org) |
Dojo Toolkit 1.7 Released.(dojotoolkit.org) |
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.
Well, that's not really quite the background to call the dojo widgets useless. They are a really useful set of _programmable_ widgets.
Aye, they _might_ appear to be useless to developers used to cut & paste, but if you delve a little deeper you will discover a world of useful UI widgets that can fulfill most of your needs for rich web applications.
If your needs aren't fulfilled with the provided widgets you can always make your own or modify the existing ones with the tools provided, that I must say are great at it.
How is using dojo widgets not "cut and paste"? Thats exactly what cut and paste is, all the jQuery stuff we develop is our own, not cut and pasted. If we really wanted to use dojo widgets, some in the team would have to dig deep into dijit, which makes the whole thing useless since they might as well develop their own "widgets" using jquery in less time, and less maintenence, and less dependency on yet another abstraction/library.
dojoAttachPoint is an attribute dojo uses in widget templates. I don't really know what you would propose to replace it (except data-attachPoint, say). If you're going to design a tempting system you need a binding mechanism, and that's what dojo does.
You can't complain too much about abusing the liberty HTML has always allowed with unrecognized attributes. Dojo cleverly leveraged the capability. And frameworks like dojo are the very reason we even have data-blah now.
Unless you are designing widget templates, you can do everything in dojo programmatically, if you choose, and keep your HTML pure. But, why?
Separate looks and from behaviour. The HTML is created already from another templating system server-side, its a pure hell to introduce HTML from Javascript and mix it.
Some UI widgets (Dijits) choose to use a client-side HTML fragment, but others do not have that requirement. Some of the work on projects like xstyle and put-selector seek to reduce this reliance further.
Dijits can be invoked either through extra markup in your base HTML page, or through a JS constructor. In the HTML templated widgets, there are attributes that bind DOM nodes to reference variables in your JS, so the widget knows where to insert content, or subwidgets, etc., and where to attach DOM events. The HTML isn't stored in JS, it's stored in an HTML file that gets combined through build tools (so you don't need to do this mix in process, it just works).
But again, that's an optional feature that's used primarily by the widget system and some of the widgets in Dojo.
And the general point is that Dojo can do a lot more than jQuery- for one, it works outside of the browser. A library like MooTools is the same. jQuery is, at it's heart, a DOM manipulation tool. Dojo and the others are more complete libraries that aren't just for HTML.
Yes dojo is a complete library and for 99% of the use cases for a web application, it is overkill.
I use dojo daily, and I find everything to be well-written and high quality. It's the documentation that has always been a train wreck. Their idea of improving the documentation is reorganizing it on a new website.
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 answer is: yes, it has a future in a wide range of places. But in the subset of DOM manipulation, it might be more appropriate to use jQuery.
