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

Revin Guillen rg at sevenite.com
Thu Oct 11 15:42:46 EDT 2012

I don't think anyone disagrees with this. In this case I'd call the first snippet "higher level" and the second "low level", and create the first snippet's API as an abstraction layer on top of the second. The first one might look simpler to a programmer, but as you say, there's magic inside, and that magic is expressed in terms of lower level building blocks. A more advanced user like yourself would just use or build on the lower level building blocks directly.

I obviously can't speak for Rawld et al, but at least what *I've* been trying to say is definitely NOT that "simpler" and "low level" are the same. The Simple is in DTK user UX, not DTK developer UX. Does that make more sense?

Revin Guillen :: Sevenite Inc
rg at sevenite.com

On Oct 11, 2012, at Oct 11 | 12:22 PM, Bryan Forbes wrote:

> 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
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

More information about the dojo-contributors mailing list