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

Ken Benjamin kenbenjamin at kenbenjamin.net
Thu Oct 11 15:48:42 EDT 2012

This tiny tutorial is just the kind of thing I'm proposing we need.

No need to oversimplify, just explain and show the benefits.

More to type, okay, better to use, super!

Ken B

-----Original Message-----
From: dojo-contributors-bounces at mail.dojotoolkit.org
[mailto:dojo-contributors-bounces at mail.dojotoolkit.org] On Behalf Of Bryan
Sent: Thursday, October 11, 2012 9:22 PM
To: dojo dev.
Subject: Re: [dojo-contributors] what is the raison detre for dojo 2.0.

Rawld Gill wrote:
> I am not trying to be a jerk, but from an engineering pov, I don't
> understand why a simple, optimal, easy [e.g.] dom api that's is an end
> point is different than a dom api that is used to construct higher-level
> abstractions.
> I'm *NOT* arguing we should copy JQuery or anybody else. I am arguing that
> the goal should be to have every one of our APIs be every bit as simple,
> optimal, easy as any competing API.
> Can you give me an example (as in a specific function or group of
> functions) of where it is impossible to build a low-level API targeted as
> an end point in and of itself that does not imply a cost when it is used
> as a block in a higher level abstraction?

I think the problem is the use of subjective terms like "simple" and "easy".
Let's take a use-case and look at how you do things in the jQuery world and
how you do things in the Dojo world: get an element by its ID, add a class
to it, and modify some styles. First, jQuery (correct me if I'm wrong about
this code because I'm just going by how I'm reading the docs):

		display: 'block',
		width: '400px'

And now, Dojo:

], 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.
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
* 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.

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.

Bryan Forbes

GPG Fingerprint
3D7D B728 713A BB7B B8B1  5B61 3888 17E0 70CA 0F3D

More information about the dojo-contributors mailing list