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

Bryan Forbes bryan at reigndropsfall.net
Thu Oct 11 15:22:03 EDT 2012


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):

$('#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.
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.
* 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
http://www.reigndropsfall.net

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
Url : http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20121011/60121d3b/attachment.sig 


More information about the dojo-contributors mailing list