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

Tom Trenka ttrenka at gmail.com
Thu Oct 4 12:51:06 EDT 2012


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> 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> 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> 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
>>> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20121004/321f89f8/attachment.htm 


More information about the dojo-contributors mailing list