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

Kenneth G. Franqueiro kgf at dojotoolkit.org
Thu Oct 4 13:16:03 EDT 2012


I am one of those who have some arguments against it.  While the most
basic features may be nice, there are way too many things in it that
just become impossible to grok.  I do not want us establishing 2.0 based
on APIs that lead to (and possibly are made of) terribly unreadable code.

I'm also not sure whether it's intended to replace all of the APIs you
mention... I see it as a shortcut for domConstruct.create basically, but
I'd sooner argue that domConstruct.create ends up with far more readable
(though obviously longer) code.

Anyway, I think the point of this discussion was not to digress into
feature lists.  I am still thinking about my answer, and that sorta
depends on which interpretation of the question was intended.

--Ken

On 10/4/2012 12:51 PM, Tom Trenka wrote:
> One thing I forgot to add in this list; I would *love* to see Kris Zyp's
> put-selector/put become our standard DOM manipulation library.  I know
> some people have some arguments against it, but I've never used a more
> simple API to do any kind of DOM creation/manipulation before.  I mean,
> its super simple to use, is very efficient, and small as all hell.  The
> only two pet peeves I have about it is that it doesn't have any kind of
> getters (i.e. dom.byId, that kind of thing), which is
> understandable...and it doesn't seem to handle setting style information
> directly well.  The latter is always solved by using element.style.foo,
> but having some kind of similar API like dojo/dom-style would be a
> definite "nice-to-have".
> 
> Cheers--
> Tom
> 
> On Thu, Oct 4, 2012 at 9:08 AM, Tom Trenka <ttrenka at gmail.com
> <mailto:ttrenka at gmail.com>> wrote:
> 
>     I was under the same impression as Bill, and so in lieu of what
>     sounds like a basic mission statement, and without getting too far
>     into features, I'll throw in my two cents for why a Dojo 2.0:
> 
>     1) Dropping IE8 and lower cruft, allowing us to significantly clean
>     and reorganize core.
>     2) Relying on ES5 shim instead of implementing our own native object
>     fixes.
>     3) A full move (which we've been gradually doing on the 1.x branch)
>     to true AMD (i.e. remove the dojo.require/provide cruft entirely).
>     4) A full move towards those APIs which have begun to appear in
>     1.6+: dojo/on, dojo/Promise, dojo/Request
>     5) Better/more streamlined query support + Nodelist operations.
>     6) Probably a rewrite of Animation to take better advantage of some
>     of the newer APIs out there.
>     7) Continued development of dojo/store.
>     8) Better/greater support for HTML5 features, including support for
>     things like audio/video directly in Core.
>     9) IMHO, a streamlined gfx (dropping support for VML) to be in core.
>     10) Streamlined (if need be) i18n facilities.
> 
>     Nice to haves:
>     1) an AMD-based unit testing platform.
>     2) Consistent, very easy-to-use auxiliary tools (aka build/doc tools)
> 
>     I think, after long reflection, that we should not move away from
>     declare at all as well; I'm a fan of ComposeJS, but after thinking
>     long and hard about it I think declare (especially with the
>     introduction of anonymous declare) should remain our object composer
>     of choice.
> 
>     The main reason I see Dojo 2.0 as a major opportunity for a real
>     rewrite is because by dropping IE8 and lower support, a good portion
>     of the things we have in Core can simply disappear--and that, in
>     effect, means that we have the opportunity to *really* take a hard
>     look at the idea of "what do we want out of a base library", and
>     code it to that effect.  I think there's still a bit of "well, we
>     don't want to touch that" mentality right now but I'd argue that we
>     should, indeed, touch that.
> 
>     I'd also suggest that certain things (particularly the parser) be
>     moved out of Core and into Dijit, and thinking long and hard about
>     what a great Core should contain should not be limited to the idea
>     of moving things out of the core library into more appropriate
>     places.  We should also be trying to approach this as "a set of
>     useful subpackages, each of which does its best to be standalone"; a
>     release would be a collection of these subpackages, any of which (as
>     best can be) used independently of each other.  For example, if I'm
>     in a situation where all I really want is Ajax facilities (i.e.
>     dojo/request), I should be able to use that with the least amount of
>     dependency as possible (IIRC, Promise is the main dependency there,
>     which is fine).
> 
>     Also...though I'm not completely sold on this particular idea, I'm
>     thinking that DnD should be moved out of core and possibly into its
>     own package.  Definitely not sure about that, though.
> 
>     Regards--
>     Tom
> 
> 
>     On Thu, Oct 4, 2012 at 7:55 AM, Kitson Kelly <me at kitsonkelly.com
>     <mailto:me at kitsonkelly.com>> wrote:
> 
>         Well, I took it as /raison d'être/, purpose for being.  Just
>         because it is similar to the purpose for Dojo 1.X in my mind
>         doesn't negate that.  If we are trying to answer what is
>         different in Dojo 2, then I think we would quickly degrade into
>         features discussion.  The "why" is far more banal of a "in order
>         to continue to be relevant, we have to break
>         backwards compatibility, which we won't do for 1.X".  That as a
>         /raison d'être/ is pretty poor IMO.
> 
>         On 4 October 2012 10:21, Bill Keese <bill at dojotoolkit.org
>         <mailto:bill at dojotoolkit.org>> wrote:
> 
>             Did I misunderstand the question?    I thought it meant "Why
>             are we releasing a version 2 of dojo?" or "How should
>             version 2 be different than version 1?", not "What's the
>             purpose of dojo in general?"
>             _______________________________________________
>             dojo-contributors mailing list
>             dojo-contributors at mail.dojotoolkit.org
>             <mailto:dojo-contributors at mail.dojotoolkit.org>
>             http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
> 
> 
> 
>         _______________________________________________
>         dojo-contributors mailing list
>         dojo-contributors at mail.dojotoolkit.org
>         <mailto:dojo-contributors at mail.dojotoolkit.org>
>         http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
> 
> 
> 
> 
> 
> _______________________________________________
> 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