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

Kenneth G. Franqueiro kgf at dojotoolkit.org
Thu Oct 11 15:50:09 EDT 2012

Indeed.  +100 to Forbes.  This is what we need to do - educate people as
to "yes, this *looks* more complicated, but if you think like a
programmer, it's actually more readable and maintainable and here's why."

--Ken F

On 10/11/2012 3:48 PM, Ken Benjamin wrote:
> 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
> Forbes
> 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):
> $('#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