[dojo-contributors] what is the raison detre for dojo 2.0.

Rawld Gill rgill at altoviso.com
Thu Oct 11 15:40:09 EDT 2012

Thank you Bryan Forbes! Inline.

> From: Bryan Forbes
> Rawld Gill wrote:
> > Can you give me an example 
> First, jQuery 
> $('#foo')
> 	.addClass('some-class')
> 	.css({
> 		display: 'block',
> 		width: '400px'
> 	});
> And now, Dojo:
> require([
> 	'dojo/dom',
> 	'dojo/dom-class',
> 	'dojo/dom-style'
> ], function(dom, domClass, domStyle){
> 	var node = dom.byId('foo');
> 	domClass.add(node, 'some-class');
> 	domStyle.set(node, {
> 		display: 'block',
> 		width: '400px'
> 	});
> });
> Alright, so jQuery, on its face looks "easier" and "simpler". It's far less to type
> (even disregarding the AMD boilerplate), and I don't have to call a bunch of
> functions and reference `node` over and over.

Right. But we could certainly have a release artifact with 2.0 that eliminates the loader and AMD for simple use cases like this. That would reduce the dojo example to three function calls...the same as the counter example.

> However, I would posit that Dojo's way is "easier" and "simpler" for some
> very different (and better, IMO) ways:
> * If all that needs to be done is what we're doing in this example, with Dojo I
> won't be bringing in code I don't need like advanced animations or the ability
> to query with custom selectors. You get that no matter what with jQuery.

Agree. And further, there are ways to accomplish this even after developing with a "nano release artifact" with the builder...another thing to think about for 2.0.

> * Although I have to get a reference to `node` and pass it to two functions,
> I'm also not creating a one element array that is iterated over in a for-loop in
> each of the functions I'm passing it to. In a large application, I won't want to
> spend a lot of time on unnecessary things if I have lots to do in the
> background.


> * In addition, I'm guessing there's some for-loop adapting going on in the
> jQuery code which is creating function executions that really aren't needed in
> the one node case.


> * I would also say that Dojo's code is easier to read. I know exactly what is
> going into where. With jQuery's code, I need to know if a node list is returned
> from the chained function before I can chain off of it.
> And is it the same node list or a different one?


> * AMD also makes organizing your code far less painful. Yes, you have to do
> the boilerplate song and dance, but you don't have to do the script tag
> inclusion song and dance anymore.

Agree, and that's important if your small app grows into a big app.

> So, although Dojo's code isn't "easier" or "simpler" to type, it's "easier" to
> make performant applications and "simpler" to make those applications
> maintainable. Yes, easy to use APIs are nice, however sometimes (I would say
> most times) those come with a penalty. So then it's a matter of deciding what
> penalties we want to incur or want to force on our users.

This is where we differ. I think Dojo is "as easy" and "as simple"...if (for this example) we can eliminate the need for the boilerplate for the subset of users that don't need AMD capabilities. And those users will then be using a soln (Dojo) that has all the great capabilities you noted...*when but not before* they need them.

I also note (and I think this is agreed) that there are places where we need to clean up our API a bit so lower-level API is as simple everywhere as it is in this example.


More information about the dojo-contributors mailing list