Dojo Toolkit 1.7 Released.(dojotoolkit.org)
dojotoolkit.org
Dojo Toolkit 1.7 Released.
http://dojotoolkit.org/blog/dojo-1-7-released
3 comments
Havre you looked into the dojo build system? That's how you make your single minified js file. Pretty straightforward, I think? http://dojotoolkit.org/reference-guide/build/
Yep, but sadly I've made a few attempts and failed miserably.
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
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
Have a look at http://build.dojotoolkit.org/ (though I never used it myself, I'm using their command line build tool).
http://build.dojotoolkit.org/ should soon be updated for 1.7. The CDN will be available asap.
Wow, thank you! How did I miss this? You have no idea how happy this made me.
Pretty starightfoward until you hit a hard-to-google for problem. Yesterday my build process was crashing because I used Windows backslashes in a command line argument instead of the Unix slashes that it expected :(
An app I use is still on dojo 0.4 because they rewrote the tree widget after 0.6 and the new implementation was missing features we depended on, I think it was different icons for leafs. Maybe time for an update now
And not a single fuck was given.
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.
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.
> 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?
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.
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.
Most apps I worked on required only querying and events. Animations can be done with css3, but if we wherent working with html5 then simple fadein/out animations are also required.
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.
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.
"Most apps I worked on required only querying and events."
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.
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.
Because there is really no need for the widgets dojo provides. In every project where a widget kind of thing was required - the requirement also included it to be developed in house, exactly suited to our needs. If we would have chosen dojo widgets we would have had to alter them heavily to do what we want, the way we want it, the way it fits with our codebase. We did that once though, and learned not do try that again.
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.
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.
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.
* 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.
Dojo is extremely modular (unlike jQuery which is has a pretty big monolithic core and overloads $ for almost everything).
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.
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.
That modularity is nice in theory, but Dojo gives me 170kb of compressed javascript simply for selecting the fileuploader widget. I saw the same for Google Closure Library by the way - not saying I could write an all purpose js library which would score better.
That's one of the major things that 1.7 fixes and 1.8 will fix even further... smaller modules and finer-grained dependencies so you aren't pulling in nearly as much base code for each feature.
Dojo gets a lot of use in the corporate world because it's so complete, particularly in terms of GUI widgets.
I always use jQuery myself, but I'm still not satisfied with any of the jQuery grid components, for example. It's disappointing.
I always use jQuery myself, but I'm still not satisfied with any of the jQuery grid components, for example. It's disappointing.
You might be interested in the dgrid project (see slides at http://www.slideshare.net/sitepen/dgrid-next-generation-dojo... and blog post at http://www.sitepen.com/blog/2011/10/26/introducing-the-next-... ). It's a new module, and one of the interesting features is support for the jQuery ThemeRoller classes. It's pretty lightweight, and could be used with jQuery with something like RequireJS, etc.
When was it that you used it? I haven't used it lately, and when I did I felt the same as you, but for what I've seen Dojo is no longer the "kitchen sink" it used to be. It's small, VERY modular, and has a lot of utilities and interesting things.
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.
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.
It's true, the docs aren't exactly good (and there are like, 3 versions of it floating around - which one to reference?).
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.
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.
Ive used it against my wish, but it may be also because of inexperience with it which makes me judge so badly. I could have done what I was doing in jQuery far more faster and effecient, and the resulting code would have been easier to maintain for many other developers. Very few know dojo.
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.
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.
HTML validation is overrated. Lots of HTML5 features, like data attributes and the shorter doctype, where there all along and just happend to be standardized now.
data-blah is HTML 5 legal and dojo is changing its patterns to use it.
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?
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?
Because I, for one, would like to keep my HTML separate from my Javascript.
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.
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.
That's fine. Dojo doesn't make this decision for you. Instead it gives you a full range of tools to choose for yourself how you want this to work.
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.
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.
jQuery often uses "data-blah" as an attribute- that isn't any more or less valid than "dojoAttachPoint".
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.
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.
It is not required by jQuery to use "data-blah" in any html tag. Developing a dojo widget requires me to break html validation. I can perfectly fine use jquery without the data-blah attributes.
Yes dojo is a complete library and for 99% of the use cases for a web application, it is overkill.
Yes dojo is a complete library and for 99% of the use cases for a web application, it is overkill.
I also think that using html tags is a poor practice. That said, Dojo does not require it for anything.
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.
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.
It is modular, you only use the modules you need, and you only load the javascript you need. As for data-*, you only use that if you want, it is a feature provided by another module. If you don't like it then don't use that feature and don't load that module ('dojo/parser'). You can create widgets programatically like in jQuery (and thats what I do).
So to answer the original question:
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.
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.
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?)