I wanted to throw out some more thoughts on Dojo future and 2.0 and
mobile. I

have previously advocated delaying 2.0 as long as possible and trying
to evolve the 1.x codebase as much as possible. However, as the need
for a mobile presence is continuing to rise, and looking at what is
needed for Dojo to be the greatest mobile framework on the planet, I
think it is increasingly evident that 1.x base is too big and in many
situations is non-optimal as an assumed include for creating lightweight mobile web
applications. This is painfully demonstrated as we see that the Dojo
committers themselves that are working on mobile additions are not
willing to rely on Dojo base anymore. dojox.mobile.scrollable has
self-bootstrapping system so it can run without dojo, dojox.mobile
includes custom builds of dojo.js and Uxebu created
EmbedJS to avoid the excessive size of Dojo base and it's modules.

For the past year various Dojo committers have played around with
various different projects and ideas that might fit into Dojo 2.0.
These divergent paths have been very helpful, and there has been some
fantastic progress in modularizing, optimizing, and shrinking
Dojo-esque/Dojo-future modules. However, I think we need to start being able to
utilize this stuff for the mobile side of things sooner rather than
later, and perhaps we need to start looking at picking some of these
paths and converging our efforts for Dojo 2.0. Even if Dojo 2.0 is not
right around the corner, the need for the improved, more modularized
components many of you have been working is immediate. I think it is
important that Dojo mobile developers (like dojox.mobile and Wink) can
start using components from EmbedJS, Uber.js, has.js, etc. The most
critical thing we need now for this to work is basic interoperability.
We really need AMD and CommonJS packaging for these projects. One of
the reason I wanted to get the package system out there is so people
could easily share these projects and start building things that
utilize modules from different ones.

Of course in the short term we aren't going to drop 1.x tomorrow. But again by looking at 2.0 it will help shape our progress with 1.x. I think on of the most important short term need is for
these to be AMD compatible and packaged so mobile developers can start
depending on, require()ing, using them (not just within EmbedJS,
other's own system). AMD helps decouple us from particular
implementations and allows us to more freely build components on
a variety of different base modules. We can also be more explicit on modules from base that we rely on (like "dojo/connect" for example), rather than always assuming the presence of base. This makes it much more feasible to create alternate builds of Dojo base and progress towards more a modular future in 2.0.

Here are some the projects that have been tossed around. I wanted to
give my thoughts on some the strong points from each of these that I
think deserve extra focus and attention as on track for Dojo 2.0 and our progress towards it. Perhaps there is or should be a wiki page to start flushing this stuff
out more. Anyway, as far as some good stuff out there, IMO:

http://github.com/phiggins42/has.js - Yes, we should be using this for
feature detection. After AMD conversion, this is the next most
important convention to follow so can have consistent feature
detection that can be handled by builds (creating different builds
based on device/feature sets). RequireJS 0.22 now supports build-level
handling of has() branches. Which is awesome.

http://github.com/phiggins42/uber.js - Peter and Bryan have done some
great working demonstrating how modules can be written using has()
feature detection in this project. The "array", "string", and
"function" modules are some great modules for demonstrating that.
Bryan and I have also been talking about some strategies with events
and AOP to minimize code size. Eugene had a great suggestion, that we
should separate AOP and events. I'd like to clarify how I believe this
delineation should be made. This is not DOM vs plain objects, but AOP
vs events, non-DOM objects should be able to be event
emitters/listeners as well. Along these lines, I have suggested that
an event listening function should have a super light branch for
standards-based addEventListener, and if not available (IE <9) then
depend on (maximize reuse) AOP code for DOM0 event handling (and don't
waste bytes on having attachEvent code). Also, I would like to have
consistency in our static AOP functions that operate on existing
objects and the AOP decorators I have suggested for use in class
creation (see next project down). before/after/around should mean the
same thing whether it be on an existing object or a superclass.
The uber.js modules would need to be upgraded to AMD format to use in
Dojo 2. Bryan said he was planning on doing that.

http://github.com/kriszyp/compose - The is an OO class that I proposed
as a replacement for dojo.declare. The documentation should explain
it, but it is intended to be much lighter and is influenced by traits,
mixins, AOP, and decorators. This uses AOP decorators to achieve super
calls.

http://github.com/uxebu/embedjs - This is an awesome effort, lot's of
cool stuff has been done here. However, any EmbedJS stuff that goes
into Dojo 2.0 needs to get upgraded to AMD module format. Some of the
individual parts of EmbedJS that I'd specifically like to see Dojo 2:
* query - Awesome, I totally love what uxebu has done with query,
this is the way to go.
* async - I like how the main promise module is light, and they only
load the back-compat API if necessary, good work.
* uri - yeah, objectToQuery should be broken out of xhr.
* array - Users can choose whether or not to apply array extras to
Array.prototype (by loading native). Smart way to go.
And lots of other modularization that is great.

https://github.com/blowery/dojo-on - I am definitely a fan of spelling
our event registration function "on()", it is succinct, matches
NodeJS, and reads well. I am definitely not a fan of requiring the
callback to provided in a separate then() call. Simple three argument
(node, eventType, listener) calls for registering event handlers is
the bread and butter of apps and shouldn't be complicated. We could
return a promise compatible object from on() calls, but we still need
to support providing the listener in the initial call. However, that
being said, I would like to the event registration handled by compose
(see below) to reuse the same code for AOP, super calls, event
registration, and pubsub.

http://bdframework.org/docs/loader/loader.html - Yes, pretty sure we
want to use this. We have put a lot of effort in getting ready for
this. Of course we also want to have RequireJS compatibility as well.
Rawld has done an awesome job replicating the important features of
RequireJS with a lightweight Dojo-ready version.

http://github.com/uhop/pulsar - Eugene has jotted down a lot of good
ideas in the comments on these modules. Both Eugene and Uxebu have hit
on the need to break up html/dom. It is far too big as a single
module. The project also nicely demonstrates our future package layout

http://github.com/unscriptable/cujo - Looks like John is doing some
great stuff with MVC. We really need to get better data binding
support, I think.

Rahul demonstrating a great data-binding system as well. It would be
great to be able to move forward with this.

Ben Hockey has been looking into higher level framework infrastructure as well.

Other modules to think about:

- json - We should feature detect and branch, using native JSON if
available.

- jsonp - This is actually completely unneeded now because it is a
subset of AMD. We could a put module somewhere if we need to catch
people's attention, but RequireJS and Backdraft should be able to
JSONP OOTB by virtue of their module loading capability.


- Separating general CSS look and feel from component specific CSS
layout. We discussed this in another thread, and I still think we need
a more extensible and easier to use theming system, and the ability to
declare CSS as a dependency so users don't have to manually do it.
Dustin and I have been talking about this, based on problems in
earlier versions of Dojo when this was attempted to some degree. Some
of the issues:
* Script ordering is very important, loading a CSS that might load
another CSS which unexpectedly takes precedence over something that
was trying to override it must be avoided. We can't support transitive
dependencies that would allow this to take place.
* IE has a 31 stylesheet limit. I think this can be overcome by
aggregating stylesheets when the limit is hit.
* This should be done as an AMD plugin. John Hann has some code that
does this already: http://github.com/unscriptable/cssx
* There are two ways to load CSS, via XHR and inserting the response
as CSS into a stylesheet, or creating a stylesheet with a src that
points to the CSS to be loaded. Loading using src attribute is
probably faster and easier. XHR could allow us to do processing on the
CSS (supporting variables at runtime, doing proactive CSS3
adjustments), but it is problematic for cross-domain and requires
adjusting relative urls to match the CSS source's path. I'd prefer to
use src to keep things as small as possible.
* Ideally a theme is nothing more than generic CSS class definitions
that are agnostic and decoupled from specific widget implementations,
but there are times when individual components may need extra
theme-specific CSS. We may want our CSS plugin to support
theme-specific branching. The key here is that new components should
be able to have theme specific CSS without adding CSS to the theme
directory, and one should be able to create a new theme without adding
to the individual component directories.
* Even if we decide that this may be overly painful to retrofit
existing widgets, we can and should be considering applying this
concepts with new widgets, particularly in the mobile space, where
selective loading could really help us to minimize downloaded bytes.

Another cool idea that I see people doing is providing backwards
compatiblity shims for CSS3 usage. I think that is being done in
dojox.mobile and John has worked on that here as well:
http://github.com/unscriptable/cssx

- lang.js type checking (is.js in EmbedJS) - Please, this atrocity can
not see the light of day in Dojo 2.0. Using dojo.isString(value)
instead typeof value == "string", is slower, increases the size of our
library, and allows primitive wrappers to permeate code (timebombs
that we should be trying to eliminate).

Other related notes include our new object store API (although that is already in 1.6), and moving GFX/Charting directly into Dojo core.

Also, here are some more thoughts on dojox.mobile itself.

- HTML5 elements (particularly form elements) - We really need to have
a parser that can scan HTML for new HTML5 elements and back-shim with
our widgets when the current browser doesn't natively support them.
For the most part, this actually should not be very difficult to do,
it is basically a matter of looking for <input>'s, finding the ones
with a "type" that the browser doesn't support, and instantiating them
with any necessary mappings to make sure our attributes match html5's.
I think the most challenging part of this could be if we want to do
build integration that can branch for different platforms to include
or not include the widgets that are necessary to back-shim (since the
main point is to reduce code size with native components). This type
of parser could be created at anytime (doesn't need to wait for 2.0 or
anything).

- I'd love to see some consistency with list/grid handling such that
the mobile list widgets and the desktop grids could inherit from a
common hierarchy such that all would support arrays, inline <li> or
<tr>'s, or stores for input.

- Helpers to assist to with device normalization. I would think that a
true multi-device web application might be structured like:
* iphone - Load simple list, use HTML5 form, use iphone.css, light
mobile widgets, no accessibility (hopefully 20-30K)
* android - Load simple list, use HTML5 form, use android.css, light
mobile widgets, no accessibility (hopefully 20-30K)
* Desktop Firefox (or other modern HTML5 browser) - Use multiple
column grid, use claro.css, desktop widgets with accessibility (hopefully 50-100K)
* IE - Load claro.css, desktop widgets, HTML5 shim widgets
(DateTextBox, ValidationTextBox, etc.), memory-leak protection, (and
anything else we can download to give them a slower more painful
experience :) . (100 - 150K)

I think there a lot we could do to help with branching and loading different CSS, and making easy to create builds for different platforms and run-time branching to them.

Anyway, hopefully these thoughts could help organize our efforts and focus our various projects to coalesce towards mobile-ready Dojo awesomeness.

--
Thanks,
Kris

Search Discussions

  • Kris Zyp at Jan 9, 2011 at 10:46 pm
    I wanted to throw out some more thoughts on Dojo future and 2.0 and
    mobile. I have previously advocated delaying 2.0 as long as possible and trying
    to evolve the 1.x codebase as much as possible. However, as the need
    for a mobile presence is continuing to rise, and looking at what is
    needed for Dojo to be the greatest mobile framework on the planet, I
    think it is increasingly evident that 1.x base is too big and in many
    situations is non-optimal as an assumed include for creating lightweight mobile web
    applications. This is painfully demonstrated as we see that the Dojo
    committers themselves that are working on mobile additions are not
    willing to rely on Dojo base anymore. dojox.mobile.scrollable has
    self-bootstrapping system so it can run without dojo, dojox.mobile
    includes custom builds of dojo.js and Uxebu created
    EmbedJS to avoid the excessive size of Dojo base and it's modules.

    For the past year various Dojo committers have played around with
    various different projects and ideas that might fit into Dojo 2.0.
    These divergent paths have been very helpful, and there has been some
    fantastic progress in modularizing, optimizing, and shrinking
    Dojo-esque/Dojo-future modules. However, I think we need to start being able to
    utilize this stuff for the mobile side of things sooner rather than
    later, and perhaps we need to start looking at picking some of these
    paths and converging our efforts for Dojo 2.0. Even if Dojo 2.0 is not
    right around the corner, the need for the improved, more modularized
    components many of you have been working is immediate. I think it is
    important that Dojo mobile developers (like dojox.mobile and Wink) can
    start using components from EmbedJS, Uber.js, has.js, etc. The most
    critical thing we need now for this to work is basic interoperability.
    We really need AMD and CommonJS packaging for these projects. One of
    the reason I wanted to get the package system out there is so people
    could easily share these projects and start building things that
    utilize modules from different ones.

    Of course in the short term we aren't going to drop 1.x tomorrow. But again by looking at 2.0 it will help shape our progress with 1.x. I think on of the most important short term need is for
    these to be AMD compatible and packaged so mobile developers can start
    depending on, require()ing, using them (not just within EmbedJS,
    other's own system). AMD helps decouple us from particular
    implementations and allows us to more freely build components on
    a variety of different base modules. We can also be more explicit on modules from base that we rely on (like "dojo/connect" for example), rather than always assuming the presence of base. This makes it much more feasible to create alternate builds of Dojo base and progress towards more a modular future in 2.0.

    Here are some the projects that have been tossed around. I wanted to
    give my thoughts on some the strong points from each of these that I
    think deserve extra focus and attention as on track for Dojo 2.0 and our progress towards it. Perhaps there is or should be a wiki page to start flushing this stuff
    out more. Anyway, as far as some good stuff out there, IMO:

    http://github.com/phiggins42/has.js - Yes, we should be using this for
    feature detection. After AMD conversion, this is the next most
    important convention to follow so can have consistent feature
    detection that can be handled by builds (creating different builds
    based on device/feature sets). RequireJS 0.22 now supports build-level
    handling of has() branches. Which is awesome.

    http://github.com/phiggins42/uber.js - Peter and Bryan have done some
    great working demonstrating how modules can be written using has()
    feature detection in this project. The "array", "string", and
    "function" modules are some great modules for demonstrating that.
    Bryan and I have also been talking about some strategies with events
    and AOP to minimize code size. Eugene had a great suggestion, that we
    should separate AOP and events. I'd like to clarify how I believe this
    delineation should be made. This is not DOM vs plain objects, but AOP
    vs events, non-DOM objects should be able to be event
    emitters/listeners as well. Along these lines, I have suggested that
    an event listening function should have a super light branch for
    standards-based addEventListener, and if not available (IE <9) then
    depend on (maximize reuse) AOP code for DOM0 event handling (and don't
    waste bytes on having attachEvent code). Also, I would like to have
    consistency in our static AOP functions that operate on existing
    objects and the AOP decorators I have suggested for use in class
    creation (see next project down). before/after/around should mean the
    same thing whether it be on an existing object or a superclass.
    The uber.js modules would need to be upgraded to AMD format to use in
    Dojo 2. Bryan said he was planning on doing that.

    http://github.com/kriszyp/compose - The is an OO class that I proposed
    as a replacement for dojo.declare. The documentation should explain
    it, but it is intended to be much lighter and is influenced by traits,
    mixins, AOP, and decorators. This uses AOP decorators to achieve super
    calls.

    http://github.com/uxebu/embedjs - This is an awesome effort, lot's of
    cool stuff has been done here. However, any EmbedJS stuff that goes
    into Dojo 2.0 needs to get upgraded to AMD module format. Some of the
    individual parts of EmbedJS that I'd specifically like to see Dojo 2:
    * query - Awesome, I totally love what uxebu has done with query,
    this is the way to go.
    * async - I like how the main promise module is light, and they only
    load the back-compat API if necessary, good work.
    * uri - yeah, objectToQuery should be broken out of xhr.
    * array - Users can choose whether or not to apply array extras to
    Array.prototype (by loading native). Smart way to go.
    And lots of other modularization that is great.

    https://github.com/blowery/dojo-on - I am definitely a fan of spelling
    our event registration function "on()", it is succinct, matches
    NodeJS, and reads well. I am definitely not a fan of requiring the
    callback to provided in a separate then() call. Simple three argument
    (node, eventType, listener) calls for registering event handlers is
    the bread and butter of apps and shouldn't be complicated. We could
    return a promise compatible object from on() calls, but we still need
    to support providing the listener in the initial call. However, that
    being said, I would like to the event registration handled by compose
    (see below) to reuse the same code for AOP, super calls, event
    registration, and pubsub.

    http://bdframework.org/docs/loader/loader.html - Yes, pretty sure we
    want to use this. We have put a lot of effort in getting ready for
    this. Of course we also want to have RequireJS compatibility as well.
    Rawld has done an awesome job replicating the important features of
    RequireJS with a lightweight Dojo-ready version.

    http://github.com/uhop/pulsar - Eugene has jotted down a lot of good
    ideas in the comments on these modules. Both Eugene and Uxebu have hit
    on the need to break up html/dom. It is far too big as a single
    module. The project also nicely demonstrates our future package layout

    http://github.com/unscriptable/cujo - Looks like John is doing some
    great stuff with MVC. We really need to get better data binding
    support, I think.

    Rahul demonstrating a great data-binding system as well. It would be
    great to be able to move forward with this.

    Ben Hockey has been looking into higher level framework infrastructure as well.

    Other modules to think about:

    - json - We should feature detect and branch, using native JSON if
    available.

    - jsonp - This is actually completely unneeded now because it is a
    subset of AMD. We could a put module somewhere if we need to catch
    people's attention, but RequireJS and Backdraft should be able to
    JSONP OOTB by virtue of their module loading capability.


    - Separating general CSS look and feel from component specific CSS
    layout. We discussed this in another thread, and I still think we need
    a more extensible and easier to use theming system, and the ability to
    declare CSS as a dependency so users don't have to manually do it.
    Dustin and I have been talking about this, based on problems in
    earlier versions of Dojo when this was attempted to some degree. Some
    of the issues:
    * Script ordering is very important, loading a CSS that might load
    another CSS which unexpectedly takes precedence over something that
    was trying to override it must be avoided. We can't support transitive
    dependencies that would allow this to take place.
    * IE has a 31 stylesheet limit. I think this can be overcome by
    aggregating stylesheets when the limit is hit.
    * This should be done as an AMD plugin. John Hann has some code that
    does this already: http://github.com/unscriptable/cssx
    * There are two ways to load CSS, via XHR and inserting the response
    as CSS into a stylesheet, or creating a stylesheet with a src that
    points to the CSS to be loaded. Loading using src attribute is
    probably faster and easier. XHR could allow us to do processing on the
    CSS (supporting variables at runtime, doing proactive CSS3
    adjustments), but it is problematic for cross-domain and requires
    adjusting relative urls to match the CSS source's path. I'd prefer to
    use src to keep things as small as possible.
    * Ideally a theme is nothing more than generic CSS class definitions
    that are agnostic and decoupled from specific widget implementations,
    but there are times when individual components may need extra
    theme-specific CSS. We may want our CSS plugin to support
    theme-specific branching. The key here is that new components should
    be able to have theme specific CSS without adding CSS to the theme
    directory, and one should be able to create a new theme without adding
    to the individual component directories.
    * Even if we decide that this may be overly painful to retrofit
    existing widgets, we can and should be considering applying this
    concepts with new widgets, particularly in the mobile space, where
    selective loading could really help us to minimize downloaded bytes.

    Another cool idea that I see people doing is providing backwards
    compatiblity shims for CSS3 usage. I think that is being done in
    dojox.mobile and John has worked on that here as well:
    http://github.com/unscriptable/cssx

    - lang.js type checking (is.js in EmbedJS) - Please, this atrocity can
    not see the light of day in Dojo 2.0. Using dojo.isString(value)
    instead typeof value == "string", is slower, increases the size of our
    library, and allows primitive wrappers to permeate code (timebombs
    that we should be trying to eliminate).

    Other related notes include our new object store API (although that is already in 1.6), and moving GFX/Charting directly into Dojo core.

    Also, here are some more thoughts on dojox.mobile itself.

    - HTML5 elements (particularly form elements) - We really need to have
    a parser that can scan HTML for new HTML5 elements and back-shim with
    our widgets when the current browser doesn't natively support them.
    For the most part, this actually should not be very difficult to do,
    it is basically a matter of looking for <input>'s, finding the ones
    with a "type" that the browser doesn't support, and instantiating them
    with any necessary mappings to make sure our attributes match html5's.
    I think the most challenging part of this could be if we want to do
    build integration that can branch for different platforms to include
    or not include the widgets that are necessary to back-shim (since the
    main point is to reduce code size with native components). This type
    of parser could be created at anytime (doesn't need to wait for 2.0 or
    anything).

    - I'd love to see some consistency with list/grid handling such that
    the mobile list widgets and the desktop grids could inherit from a
    common hierarchy such that all would support arrays, inline <li> or
    <tr>'s, or stores for input.

    - Helpers to assist to with device normalization. I would think that a
    true multi-device web application might be structured like:
    * iphone - Load simple list, use HTML5 form, use iphone.css, light
    mobile widgets, no accessibility (hopefully 20-30K)
    * android - Load simple list, use HTML5 form, use android.css, light
    mobile widgets, no accessibility (hopefully 20-30K)
    * Desktop Firefox (or other modern HTML5 browser) - Use multiple
    column grid, use claro.css, desktop widgets with accessibility (hopefully 50-100K)
    * IE - Load claro.css, desktop widgets, HTML5 shim widgets
    (DateTextBox, ValidationTextBox, etc.), memory-leak protection, (and
    anything else we can download to give them a slower more painful
    experience :) . (100 - 150K)

    I think there a lot we could do to help with branching and loading different CSS, and making easy to create builds for different platforms and run-time branching to them.

    Anyway, hopefully these thoughts could help organize our efforts and focus our various projects to coalesce towards mobile-ready Dojo awesomeness.

    --
    Thanks,
    Kris
  • Kris Zyp at Jan 9, 2011 at 11:13 pm
    I wanted to throw out some more thoughts on Dojo future and 2.0 and
    mobile. I have previously advocated delaying 2.0 as long as possible and trying
    to evolve the 1.x codebase as much as possible. However, as the need
    for a mobile presence is continuing to rise, and looking at what is
    needed for Dojo to be the greatest mobile framework on the planet, I
    think it is increasingly evident that 1.x base is too big and in many
    situations is non-optimal as an assumed include for creating lightweight mobile web
    applications. This is painfully demonstrated as we see that the Dojo
    committers themselves that are working on mobile additions are not
    willing to rely on Dojo base anymore. dojox.mobile.scrollable has
    self-bootstrapping system so it can run without dojo, dojox.mobile
    includes custom builds of dojo.js and Uxebu created
    EmbedJS to avoid the excessive size of Dojo base and it's modules.

    For the past year various Dojo committers have played around with
    various different projects and ideas that might fit into Dojo 2.0.
    These divergent paths have been very helpful, and there has been some
    fantastic progress in modularizing, optimizing, and shrinking
    Dojo-esque/Dojo-future modules. However, I think we need to start being able to
    utilize this stuff for the mobile side of things sooner rather than
    later, and perhaps we need to start looking at picking some of these
    paths and converging our efforts for Dojo 2.0. Even if Dojo 2.0 is not
    right around the corner, the need for the improved, more modularized
    components many of you have been working is immediate. I think it is
    important that Dojo mobile developers (like dojox.mobile and Wink) can
    start using components from EmbedJS, Uber.js, has.js, etc. The most
    critical thing we need now for this to work is basic interoperability.
    We really need AMD and CommonJS packaging for these projects. One of
    the reason I wanted to get the package system out there is so people
    could easily share these projects and start building things that
    utilize modules from different ones.

    Of course in the short term we aren't going to drop 1.x tomorrow. But again by looking at 2.0 it will help shape our progress with 1.x. I think on of the most important short term need is for
    these to be AMD compatible and packaged so mobile developers can start
    depending on, require()ing, using them (not just within EmbedJS,
    other's own system). AMD helps decouple us from particular
    implementations and allows us to more freely build components on
    a variety of different base modules. We can also be more explicit on modules from base that we rely on (like "dojo/connect" for example), rather than always assuming the presence of base. This makes it much more feasible to create alternate builds of Dojo base and progress towards more a modular future in 2.0.

    Here are some the projects that have been tossed around. I wanted to
    give my thoughts on some the strong points from each of these that I
    think deserve extra focus and attention as on track for Dojo 2.0 and our progress towards it. Perhaps there is or should be a wiki page to start flushing this stuff
    out more. Anyway, as far as some good stuff out there, IMO:

    http://github.com/phiggins42/has.js - Yes, we should be using this for
    feature detection. After AMD conversion, this is the next most
    important convention to follow so can have consistent feature
    detection that can be handled by builds (creating different builds
    based on device/feature sets). RequireJS 0.22 now supports build-level
    handling of has() branches. Which is awesome.

    http://github.com/phiggins42/uber.js - Peter and Bryan have done some
    great working demonstrating how modules can be written using has()
    feature detection in this project. The "array", "string", and
    "function" modules are some great modules for demonstrating that.
    Bryan and I have also been talking about some strategies with events
    and AOP to minimize code size. Eugene had a great suggestion, that we
    should separate AOP and events. I'd like to clarify how I believe this
    delineation should be made. This is not DOM vs plain objects, but AOP
    vs events, non-DOM objects should be able to be event
    emitters/listeners as well. Along these lines, I have suggested that
    an event listening function should have a super light branch for
    standards-based addEventListener, and if not available (IE <9) then
    depend on (maximize reuse) AOP code for DOM0 event handling (and don't
    waste bytes on having attachEvent code). Also, I would like to have
    consistency in our static AOP functions that operate on existing
    objects and the AOP decorators I have suggested for use in class
    creation (see next project down). before/after/around should mean the
    same thing whether it be on an existing object or a superclass.
    The uber.js modules would need to be upgraded to AMD format to use in
    Dojo 2. Bryan said he was planning on doing that.

    http://github.com/kriszyp/compose - The is an OO class that I proposed
    as a replacement for dojo.declare. The documentation should explain
    it, but it is intended to be much lighter and is influenced by traits,
    mixins, AOP, and decorators. This uses AOP decorators to achieve super
    calls.

    http://github.com/uxebu/embedjs - This is an awesome effort, lot's of
    cool stuff has been done here. However, any EmbedJS stuff that goes
    into Dojo 2.0 needs to get upgraded to AMD module format. Some of the
    individual parts of EmbedJS that I'd specifically like to see Dojo 2:
    * query - Awesome, I totally love what uxebu has done with query,
    this is the way to go.
    * async - I like how the main promise module is light, and they only
    load the back-compat API if necessary, good work.
    * uri - yeah, objectToQuery should be broken out of xhr.
    * array - Users can choose whether or not to apply array extras to
    Array.prototype (by loading native). Smart way to go.
    And lots of other modularization that is great.

    https://github.com/blowery/dojo-on - I am definitely a fan of spelling
    our event registration function "on()", it is succinct, matches
    NodeJS, and reads well. I am definitely not a fan of requiring the
    callback to provided in a separate then() call. Simple three argument
    (node, eventType, listener) calls for registering event handlers is
    the bread and butter of apps and shouldn't be complicated. We could
    return a promise compatible object from on() calls, but we still need
    to support providing the listener in the initial call. However, that
    being said, I would like to the event registration handled by compose
    (see below) to reuse the same code for AOP, super calls, event
    registration, and pubsub.

    http://bdframework.org/docs/loader/loader.html - Yes, pretty sure we
    want to use this. We have put a lot of effort in getting ready for
    this. Of course we also want to have RequireJS compatibility as well.
    Rawld has done an awesome job replicating the important features of
    RequireJS with a lightweight Dojo-ready version.

    http://github.com/uhop/pulsar - Eugene has jotted down a lot of good
    ideas in the comments on these modules. Both Eugene and Uxebu have hit
    on the need to break up html/dom. It is far too big as a single
    module. The project also nicely demonstrates our future package layout

    http://github.com/unscriptable/cujo - Looks like John is doing some
    great stuff with MVC. We really need to get better data binding
    support, I think.

    Rahul demonstrating a great data-binding system as well. It would be
    great to be able to move forward with this.

    Ben Hockey has been looking into higher level framework infrastructure as well.

    Other modules to think about:

    - json - We should feature detect and branch, using native JSON if
    available.

    - jsonp - This is actually completely unneeded now because it is a
    subset of AMD. We could a put module somewhere if we need to catch
    people's attention, but RequireJS and Backdraft should be able to
    JSONP OOTB by virtue of their module loading capability.


    - Separating general CSS look and feel from component specific CSS
    layout. We discussed this in another thread, and I still think we need
    a more extensible and easier to use theming system, and the ability to
    declare CSS as a dependency so users don't have to manually do it.
    Dustin and I have been talking about this, based on problems in
    earlier versions of Dojo when this was attempted to some degree. Some
    of the issues:
    * Script ordering is very important, loading a CSS that might load
    another CSS which unexpectedly takes precedence over something that
    was trying to override it must be avoided. We can't support transitive
    dependencies that would allow this to take place.
    * IE has a 31 stylesheet limit. I think this can be overcome by
    aggregating stylesheets when the limit is hit.
    * This should be done as an AMD plugin. John Hann has some code that
    does this already: http://github.com/unscriptable/cssx
    * There are two ways to load CSS, via XHR and inserting the response
    as CSS into a stylesheet, or creating a stylesheet with a src that
    points to the CSS to be loaded. Loading using src attribute is
    probably faster and easier. XHR could allow us to do processing on the
    CSS (supporting variables at runtime, doing proactive CSS3
    adjustments), but it is problematic for cross-domain and requires
    adjusting relative urls to match the CSS source's path. I'd prefer to
    use src to keep things as small as possible.
    * Ideally a theme is nothing more than generic CSS class definitions
    that are agnostic and decoupled from specific widget implementations,
    but there are times when individual components may need extra
    theme-specific CSS. We may want our CSS plugin to support
    theme-specific branching. The key here is that new components should
    be able to have theme specific CSS without adding CSS to the theme
    directory, and one should be able to create a new theme without adding
    to the individual component directories.
    * Even if we decide that this may be overly painful to retrofit
    existing widgets, we can and should be considering applying this
    concepts with new widgets, particularly in the mobile space, where
    selective loading could really help us to minimize downloaded bytes.

    Another cool idea that I see people doing is providing backwards
    compatiblity shims for CSS3 usage. I think that is being done in
    dojox.mobile and John has worked on that here as well:
    http://github.com/unscriptable/cssx

    - lang.js type checking (is.js in EmbedJS) - Please, this atrocity can
    not see the light of day in Dojo 2.0. Using dojo.isString(value)
    instead typeof value == "string", is slower, increases the size of our
    library, and allows primitive wrappers to permeate code (timebombs
    that we should be trying to eliminate).

    Other related notes include our new object store API (although that is already in 1.6), and moving GFX/Charting directly into Dojo core.

    Also, here are some more thoughts on dojox.mobile itself.

    - HTML5 elements (particularly form elements) - We really need to have
    a parser that can scan HTML for new HTML5 elements and back-shim with
    our widgets when the current browser doesn't natively support them.
    For the most part, this actually should not be very difficult to do,
    it is basically a matter of looking for <input>'s, finding the ones
    with a "type" that the browser doesn't support, and instantiating them
    with any necessary mappings to make sure our attributes match html5's.
    I think the most challenging part of this could be if we want to do
    build integration that can branch for different platforms to include
    or not include the widgets that are necessary to back-shim (since the
    main point is to reduce code size with native components). This type
    of parser could be created at anytime (doesn't need to wait for 2.0 or
    anything).

    - I'd love to see some consistency with list/grid handling such that
    the mobile list widgets and the desktop grids could inherit from a
    common hierarchy such that all would support arrays, inline <li> or
    <tr>'s, or stores for input.

    - Helpers to assist to with device normalization. I would think that a
    true multi-device web application might be structured like:
    * iphone - Load simple list, use HTML5 form, use iphone.css, light
    mobile widgets, no accessibility (hopefully 20-30K)
    * android - Load simple list, use HTML5 form, use android.css, light
    mobile widgets, no accessibility (hopefully 20-30K)
    * Desktop Firefox (or other modern HTML5 browser) - Use multiple
    column grid, use claro.css, desktop widgets with accessibility (hopefully 50-100K)
    * IE - Load claro.css, desktop widgets, HTML5 shim widgets
    (DateTextBox, ValidationTextBox, etc.), memory-leak protection, (and
    anything else we can download to give them a slower more painful
    experience :) . (100 - 150K)

    I think there a lot we could do to help with branching and loading different CSS, and making easy to create builds for different platforms and run-time branching to them.

    Anyway, hopefully these thoughts could help organize our efforts and focus our various projects to coalesce towards mobile-ready Dojo awesomeness.

    --
    Thanks,
    Kris
  • Kris Zyp at Jan 9, 2011 at 11:15 pm
    I wanted to throw out some more thoughts on Dojo future and 2.0 and
    mobile. I have previously advocated delaying 2.0 as long as possible and trying
    to evolve the 1.x codebase as much as possible. However, as the need
    for a mobile presence is continuing to rise, and looking at what is
    needed for Dojo to be the greatest mobile framework on the planet, I
    think it is increasingly evident that 1.x base is too big and in many
    situations is non-optimal as an assumed include for creating lightweight mobile web
    applications. This is painfully demonstrated as we see that the Dojo
    committers themselves that are working on mobile additions are not
    willing to rely on Dojo base anymore. dojox.mobile.scrollable has
    self-bootstrapping system so it can run without dojo, dojox.mobile
    includes custom builds of dojo.js and Uxebu created
    EmbedJS to avoid the excessive size of Dojo base and it's modules.

    For the past year various Dojo committers have played around with
    various different projects and ideas that might fit into Dojo 2.0.
    These divergent paths have been very helpful, and there has been some
    fantastic progress in modularizing, optimizing, and shrinking
    Dojo-esque/Dojo-future modules. However, I think we need to start being able to
    utilize this stuff for the mobile side of things sooner rather than
    later, and perhaps we need to start looking at picking some of these
    paths and converging our efforts for Dojo 2.0. Even if Dojo 2.0 is not
    right around the corner, the need for the improved, more modularized
    components many of you have been working is immediate. I think it is
    important that Dojo mobile developers (like dojox.mobile and Wink) can
    start using components from EmbedJS, Uber.js, has.js, etc. The most
    critical thing we need now for this to work is basic interoperability.
    We really need AMD and CommonJS packaging for these projects. One of
    the reason I wanted to get the package system out there is so people
    could easily share these projects and start building things that
    utilize modules from different ones.

    Of course in the short term we aren't going to drop 1.x tomorrow. But again by looking at 2.0 it will help shape our progress with 1.x. I think on of the most important short term need is for
    these to be AMD compatible and packaged so mobile developers can start
    depending on, require()ing, using them (not just within EmbedJS,
    other's own system). AMD helps decouple us from particular
    implementations and allows us to more freely build components on
    a variety of different base modules. We can also be more explicit on modules from base that we rely on (like "dojo/connect" for example), rather than always assuming the presence of base. This makes it much more feasible to create alternate builds of Dojo base and progress towards more a modular future in 2.0.

    Here are some the projects that have been tossed around. I wanted to
    give my thoughts on some the strong points from each of these that I
    think deserve extra focus and attention as on track for Dojo 2.0 and our progress towards it. Perhaps there is or should be a wiki page to start flushing this stuff
    out more. Anyway, as far as some good stuff out there, IMO:

    http://github.com/phiggins42/has.js - Yes, we should be using this for
    feature detection. After AMD conversion, this is the next most
    important convention to follow so can have consistent feature
    detection that can be handled by builds (creating different builds
    based on device/feature sets). RequireJS 0.22 now supports build-level
    handling of has() branches. Which is awesome.

    http://github.com/phiggins42/uber.js - Peter and Bryan have done some
    great working demonstrating how modules can be written using has()
    feature detection in this project. The "array", "string", and
    "function" modules are some great modules for demonstrating that.
    Bryan and I have also been talking about some strategies with events
    and AOP to minimize code size. Eugene had a great suggestion, that we
    should separate AOP and events. I'd like to clarify how I believe this
    delineation should be made. This is not DOM vs plain objects, but AOP
    vs events, non-DOM objects should be able to be event
    emitters/listeners as well. Along these lines, I have suggested that
    an event listening function should have a super light branch for
    standards-based addEventListener, and if not available (IE <9) then
    depend on (maximize reuse) AOP code for DOM0 event handling (and don't
    waste bytes on having attachEvent code). Also, I would like to have
    consistency in our static AOP functions that operate on existing
    objects and the AOP decorators I have suggested for use in class
    creation (see next project down). before/after/around should mean the
    same thing whether it be on an existing object or a superclass.
    The uber.js modules would need to be upgraded to AMD format to use in
    Dojo 2. Bryan said he was planning on doing that.

    http://github.com/kriszyp/compose - The is an OO class that I proposed
    as a replacement for dojo.declare. The documentation should explain
    it, but it is intended to be much lighter and is influenced by traits,
    mixins, AOP, and decorators. This uses AOP decorators to achieve super
    calls.

    http://github.com/uxebu/embedjs - This is an awesome effort, lot's of
    cool stuff has been done here. However, any EmbedJS stuff that goes
    into Dojo 2.0 needs to get upgraded to AMD module format. Some of the
    individual parts of EmbedJS that I'd specifically like to see Dojo 2:
    * query - Awesome, I totally love what uxebu has done with query,
    this is the way to go.
    * async - I like how the main promise module is light, and they only
    load the back-compat API if necessary, good work.
    * uri - yeah, objectToQuery should be broken out of xhr.
    * array - Users can choose whether or not to apply array extras to
    Array.prototype (by loading native). Smart way to go.
    And lots of other modularization that is great.

    https://github.com/blowery/dojo-on - I am definitely a fan of spelling
    our event registration function "on()", it is succinct, matches
    NodeJS, and reads well. I am definitely not a fan of requiring the
    callback to provided in a separate then() call. Simple three argument
    (node, eventType, listener) calls for registering event handlers is
    the bread and butter of apps and shouldn't be complicated. We could
    return a promise compatible object from on() calls, but we still need
    to support providing the listener in the initial call. However, that
    being said, I would like to the event registration handled by compose
    (see below) to reuse the same code for AOP, super calls, event
    registration, and pubsub.

    http://bdframework.org/docs/loader/loader.html - Yes, pretty sure we
    want to use this. We have put a lot of effort in getting ready for
    this. Of course we also want to have RequireJS compatibility as well.
    Rawld has done an awesome job replicating the important features of
    RequireJS with a lightweight Dojo-ready version.

    http://github.com/uhop/pulsar - Eugene has jotted down a lot of good
    ideas in the comments on these modules. Both Eugene and Uxebu have hit
    on the need to break up html/dom. It is far too big as a single
    module. The project also nicely demonstrates our future package layout

    http://github.com/unscriptable/cujo - Looks like John is doing some
    great stuff with MVC. We really need to get better data binding
    support, I think.

    Rahul demonstrating a great data-binding system as well. It would be
    great to be able to move forward with this.

    Ben Hockey has been looking into higher level framework infrastructure as well.

    Other modules to think about:

    - json - We should feature detect and branch, using native JSON if
    available.

    - jsonp - This is actually completely unneeded now because it is a
    subset of AMD. We could a put module somewhere if we need to catch
    people's attention, but RequireJS and Backdraft should be able to
    JSONP OOTB by virtue of their module loading capability.


    - Separating general CSS look and feel from component specific CSS
    layout. We discussed this in another thread, and I still think we need
    a more extensible and easier to use theming system, and the ability to
    declare CSS as a dependency so users don't have to manually do it.
    Dustin and I have been talking about this, based on problems in
    earlier versions of Dojo when this was attempted to some degree. Some
    of the issues:
    * Script ordering is very important, loading a CSS that might load
    another CSS which unexpectedly takes precedence over something that
    was trying to override it must be avoided. We can't support transitive
    dependencies that would allow this to take place.
    * IE has a 31 stylesheet limit. I think this can be overcome by
    aggregating stylesheets when the limit is hit.
    * This should be done as an AMD plugin. John Hann has some code that
    does this already: http://github.com/unscriptable/cssx
    * There are two ways to load CSS, via XHR and inserting the response
    as CSS into a stylesheet, or creating a stylesheet with a src that
    points to the CSS to be loaded. Loading using src attribute is
    probably faster and easier. XHR could allow us to do processing on the
    CSS (supporting variables at runtime, doing proactive CSS3
    adjustments), but it is problematic for cross-domain and requires
    adjusting relative urls to match the CSS source's path. I'd prefer to
    use src to keep things as small as possible.
    * Ideally a theme is nothing more than generic CSS class definitions
    that are agnostic and decoupled from specific widget implementations,
    but there are times when individual components may need extra
    theme-specific CSS. We may want our CSS plugin to support
    theme-specific branching. The key here is that new components should
    be able to have theme specific CSS without adding CSS to the theme
    directory, and one should be able to create a new theme without adding
    to the individual component directories.
    * Even if we decide that this may be overly painful to retrofit
    existing widgets, we can and should be considering applying this
    concepts with new widgets, particularly in the mobile space, where
    selective loading could really help us to minimize downloaded bytes.

    Another cool idea that I see people doing is providing backwards
    compatiblity shims for CSS3 usage. I think that is being done in
    dojox.mobile and John has worked on that here as well:
    http://github.com/unscriptable/cssx

    - lang.js type checking (is.js in EmbedJS) - Please, this atrocity can
    not see the light of day in Dojo 2.0. Using dojo.isString(value)
    instead typeof value == "string", is slower, increases the size of our
    library, and allows primitive wrappers to permeate code (timebombs
    that we should be trying to eliminate).

    Other related notes include our new object store API (although that is already in 1.6), and moving GFX/Charting directly into Dojo core.

    Also, here are some more thoughts on dojox.mobile itself.

    - HTML5 elements (particularly form elements) - We really need to have
    a parser that can scan HTML for new HTML5 elements and back-shim with
    our widgets when the current browser doesn't natively support them.
    For the most part, this actually should not be very difficult to do,
    it is basically a matter of looking for <input>'s, finding the ones
    with a "type" that the browser doesn't support, and instantiating them
    with any necessary mappings to make sure our attributes match html5's.
    I think the most challenging part of this could be if we want to do
    build integration that can branch for different platforms to include
    or not include the widgets that are necessary to back-shim (since the
    main point is to reduce code size with native components). This type
    of parser could be created at anytime (doesn't need to wait for 2.0 or
    anything).

    - I'd love to see some consistency with list/grid handling such that
    the mobile list widgets and the desktop grids could inherit from a
    common hierarchy such that all would support arrays, inline <li> or
    <tr>'s, or stores for input.

    - Helpers to assist to with device normalization. I would think that a
    true multi-device web application might be structured like:
    * iphone - Load simple list, use HTML5 form, use iphone.css, light
    mobile widgets, no accessibility (hopefully 20-30K)
    * android - Load simple list, use HTML5 form, use android.css, light
    mobile widgets, no accessibility (hopefully 20-30K)
    * Desktop Firefox (or other modern HTML5 browser) - Use multiple
    column grid, use claro.css, desktop widgets with accessibility (hopefully 50-100K)
    * IE - Load claro.css, desktop widgets, HTML5 shim widgets
    (DateTextBox, ValidationTextBox, etc.), memory-leak protection, (and
    anything else we can download to give them a slower more painful
    experience :) . (100 - 150K)

    I think there a lot we could do to help with branching and loading different CSS, and making easy to create builds for different platforms and run-time branching to them.

    Anyway, hopefully these thoughts could help organize our efforts and focus our various projects to coalesce towards mobile-ready Dojo awesomeness.

    --
    Thanks,
    Kris











    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110109/efd2a723/attachment-0001.htm
  • Kris Zyp at Jan 10, 2011 at 10:40 am
    I wanted to throw out some more thoughts on Dojo future and 2.0 and
    mobile. I have previously advocated delaying 2.0 as long as possible and trying
    to evolve the 1.x codebase as much as possible. However, as the need
    for a mobile presence is continuing to rise, and looking at what is
    needed for Dojo to be the greatest mobile framework on the planet, I
    think it is increasingly evident that 1.x base is too big and in many
    situations is non-optimal as an assumed include for creating lightweight mobile web
    applications. This is painfully demonstrated as we see that the Dojo
    committers themselves that are working on mobile additions are not
    willing to rely on Dojo base anymore. dojox.mobile.scrollable has
    self-bootstrapping system so it can run without dojo, dojox.mobile
    includes custom builds of dojo.js and Uxebu created
    EmbedJS to avoid the excessive size of Dojo base and it's modules.

    For the past year various Dojo committers have played around with
    various different projects and ideas that might fit into Dojo 2.0.
    These divergent paths have been very helpful, and there has been some
    fantastic progress in modularizing, optimizing, and shrinking
    Dojo-esque/Dojo-future modules. However, I think we need to start being able to
    utilize this stuff for the mobile side of things sooner rather than
    later, and perhaps we need to start looking at picking some of these
    paths and converging our efforts for Dojo 2.0. Even if Dojo 2.0 is not
    right around the corner, the need for the improved, more modularized
    components many of you have been working is immediate. I think it is
    important that Dojo mobile developers (like dojox.mobile and Wink) can
    start using components from EmbedJS, Uber.js, has.js, etc. The most
    critical thing we need now for this to work is basic interoperability.
    We really need AMD and CommonJS packaging for these projects. One of
    the reason I wanted to get the package system out there is so people
    could easily share these projects and start building things that
    utilize modules from different ones.

    Of course in the short term we aren't going to drop 1.x tomorrow. But again by looking at 2.0 it will help shape our progress with 1.x. I think on of the most important short term need is for
    these to be AMD compatible and packaged so mobile developers can start
    depending on, require()ing, using them (not just within EmbedJS,
    other's own system). AMD helps decouple us from particular
    implementations and allows us to more freely build components on
    a variety of different base modules. We can also be more explicit on modules from base that we rely on (like "dojo/connect" for example), rather than always assuming the presence of base. This makes it much more feasible to create alternate builds of Dojo base and progress towards more a modular future in 2.0.

    Here are some the projects that have been tossed around. I wanted to
    give my thoughts on some the strong points from each of these that I
    think deserve extra focus and attention as on track for Dojo 2.0 and our progress towards it. Perhaps there is or should be a wiki page to start flushing this stuff
    out more. Anyway, as far as some good stuff out there, IMO:

    http://github.com/phiggins42/has.js - Yes, we should be using this for
    feature detection. After AMD conversion, this is the next most
    important convention to follow so can have consistent feature
    detection that can be handled by builds (creating different builds
    based on device/feature sets). RequireJS 0.22 now supports build-level
    handling of has() branches. Which is awesome.

    http://github.com/phiggins42/uber.js - Peter and Bryan have done some
    great working demonstrating how modules can be written using has()
    feature detection in this project. The "array", "string", and
    "function" modules are some great modules for demonstrating that.
    Bryan and I have also been talking about some strategies with events
    and AOP to minimize code size. Eugene had a great suggestion, that we
    should separate AOP and events. I'd like to clarify how I believe this
    delineation should be made. This is not DOM vs plain objects, but AOP
    vs events, non-DOM objects should be able to be event
    emitters/listeners as well. Along these lines, I have suggested that
    an event listening function should have a super light branch for
    standards-based addEventListener, and if not available (IE <9) then
    depend on (maximize reuse) AOP code for DOM0 event handling (and don't
    waste bytes on having attachEvent code). Also, I would like to have
    consistency in our static AOP functions that operate on existing
    objects and the AOP decorators I have suggested for use in class
    creation (see next project down). before/after/around should mean the
    same thing whether it be on an existing object or a superclass.
    The uber.js modules would need to be upgraded to AMD format to use in
    Dojo 2. Bryan said he was planning on doing that.

    http://github.com/kriszyp/compose - The is an OO class that I proposed
    as a replacement for dojo.declare. The documentation should explain
    it, but it is intended to be much lighter and is influenced by traits,
    mixins, AOP, and decorators. This uses AOP decorators to achieve super
    calls.

    http://github.com/uxebu/embedjs - This is an awesome effort, lot's of
    cool stuff has been done here. However, any EmbedJS stuff that goes
    into Dojo 2.0 needs to get upgraded to AMD module format. Some of the
    individual parts of EmbedJS that I'd specifically like to see Dojo 2:
    * query - Awesome, I totally love what uxebu has done with query,
    this is the way to go.
    * async - I like how the main promise module is light, and they only
    load the back-compat API if necessary, good work.
    * uri - yeah, objectToQuery should be broken out of xhr.
    * array - Users can choose whether or not to apply array extras to
    Array.prototype (by loading native). Smart way to go.
    And lots of other modularization that is great.

    https://github.com/blowery/dojo-on - I am definitely a fan of spelling
    our event registration function "on()", it is succinct, matches
    NodeJS, and reads well. I am definitely not a fan of requiring the
    callback to provided in a separate then() call. Simple three argument
    (node, eventType, listener) calls for registering event handlers is
    the bread and butter of apps and shouldn't be complicated. We could
    return a promise compatible object from on() calls, but we still need
    to support providing the listener in the initial call. However, that
    being said, I would like to the event registration handled by compose
    (see below) to reuse the same code for AOP, super calls, event
    registration, and pubsub.

    http://bdframework.org/docs/loader/loader.html - Yes, pretty sure we
    want to use this. We have put a lot of effort in getting ready for
    this. Of course we also want to have RequireJS compatibility as well.
    Rawld has done an awesome job replicating the important features of
    RequireJS with a lightweight Dojo-ready version.

    http://github.com/uhop/pulsar - Eugene has jotted down a lot of good
    ideas in the comments on these modules. Both Eugene and Uxebu have hit
    on the need to break up html/dom. It is far too big as a single
    module. The project also nicely demonstrates our future package layout

    http://github.com/unscriptable/cujo - Looks like John is doing some
    great stuff with MVC. We really need to get better data binding
    support, I think.

    Rahul demonstrating a great data-binding system as well. It would be
    great to be able to move forward with this.

    Ben Hockey has been looking into higher level framework infrastructure as well.

    Other modules to think about:

    - json - We should feature detect and branch, using native JSON if
    available.

    - jsonp - This is actually completely unneeded now because it is a
    subset of AMD. We could a put module somewhere if we need to catch
    people's attention, but RequireJS and Backdraft should be able to
    JSONP OOTB by virtue of their module loading capability.


    - Separating general CSS look and feel from component specific CSS
    layout. We discussed this in another thread, and I still think we need
    a more extensible and easier to use theming system, and the ability to
    declare CSS as a dependency so users don't have to manually do it.
    Dustin and I have been talking about this, based on problems in
    earlier versions of Dojo when this was attempted to some degree. Some
    of the issues:
    * Script ordering is very important, loading a CSS that might load
    another CSS which unexpectedly takes precedence over something that
    was trying to override it must be avoided. We can't support transitive
    dependencies that would allow this to take place.
    * IE has a 31 stylesheet limit. I think this can be overcome by
    aggregating stylesheets when the limit is hit.
    * This should be done as an AMD plugin. John Hann has some code that
    does this already: http://github.com/unscriptable/cssx
    * There are two ways to load CSS, via XHR and inserting the response
    as CSS into a stylesheet, or creating a stylesheet with a src that
    points to the CSS to be loaded. Loading using src attribute is
    probably faster and easier. XHR could allow us to do processing on the
    CSS (supporting variables at runtime, doing proactive CSS3
    adjustments), but it is problematic for cross-domain and requires
    adjusting relative urls to match the CSS source's path. I'd prefer to
    use src to keep things as small as possible.
    * Ideally a theme is nothing more than generic CSS class definitions
    that are agnostic and decoupled from specific widget implementations,
    but there are times when individual components may need extra
    theme-specific CSS. We may want our CSS plugin to support
    theme-specific branching. The key here is that new components should
    be able to have theme specific CSS without adding CSS to the theme
    directory, and one should be able to create a new theme without adding
    to the individual component directories.
    * Even if we decide that this may be overly painful to retrofit
    existing widgets, we can and should be considering applying this
    concepts with new widgets, particularly in the mobile space, where
    selective loading could really help us to minimize downloaded bytes.

    Another cool idea that I see people doing is providing backwards
    compatiblity shims for CSS3 usage. I think that is being done in
    dojox.mobile and John has worked on that here as well:
    http://github.com/unscriptable/cssx

    - lang.js type checking (is.js in EmbedJS) - Please, this atrocity can
    not see the light of day in Dojo 2.0. Using dojo.isString(value)
    instead typeof value == "string", is slower, increases the size of our
    library, and allows primitive wrappers to permeate code (timebombs
    that we should be trying to eliminate).

    Other related notes include our new object store API (although that is already in 1.6), and moving GFX/Charting directly into Dojo core.

    Also, here are some more thoughts on dojox.mobile itself.

    - HTML5 elements (particularly form elements) - We really need to have
    a parser that can scan HTML for new HTML5 elements and back-shim with
    our widgets when the current browser doesn't natively support them.
    For the most part, this actually should not be very difficult to do,
    it is basically a matter of looking for <input>'s, finding the ones
    with a "type" that the browser doesn't support, and instantiating them
    with any necessary mappings to make sure our attributes match html5's.
    I think the most challenging part of this could be if we want to do
    build integration that can branch for different platforms to include
    or not include the widgets that are necessary to back-shim (since the
    main point is to reduce code size with native components). This type
    of parser could be created at anytime (doesn't need to wait for 2.0 or
    anything).

    - I'd love to see some consistency with list/grid handling such that
    the mobile list widgets and the desktop grids could inherit from a
    common hierarchy such that all would support arrays, inline <li> or
    <tr>'s, or stores for input.

    - Helpers to assist to with device normalization. I would think that a
    true multi-device web application might be structured like:
    * iphone - Load simple list, use HTML5 form, use iphone.css, light
    mobile widgets, no accessibility (hopefully 20-30K)
    * android - Load simple list, use HTML5 form, use android.css, light
    mobile widgets, no accessibility (hopefully 20-30K)
    * Desktop Firefox (or other modern HTML5 browser) - Use multiple
    column grid, use claro.css, desktop widgets with accessibility (hopefully 50-100K)
    * IE - Load claro.css, desktop widgets, HTML5 shim widgets
    (DateTextBox, ValidationTextBox, etc.), memory-leak protection, (and
    anything else we can download to give them a slower more painful
    experience :) . (100 - 150K)

    I think there a lot we could do to help with branching and loading different CSS, and making easy to create builds for different platforms and run-time branching to them.

    Anyway, hopefully these thoughts could help organize our efforts and focus our various projects to coalesce towards mobile-ready Dojo awesomeness.

    --
    Thanks,
    Kris
  • Eugene Lazutkin at Jan 10, 2011 at 4:02 pm
    Which one out of five is the most definitive one to read? This one? It
    looks the latest to me, but I may be wrong.

    Cheers,

    Eugene
    On 1/10/11 9:40 AM, Kris Zyp wrote:
    I wanted to throw out some more thoughts on Dojo future and 2.0 and
    mobile. I have previously advocated delaying 2.0 as long as possible and trying
    to evolve the 1.x codebase as much as possible. However, as the need
    for a mobile presence is continuing to rise, and looking at what is
    needed for Dojo to be the greatest mobile framework on the planet, I
    think it is increasingly evident that 1.x base is too big and in many
    situations is non-optimal as an assumed include for creating lightweight mobile web
    applications. This is painfully demonstrated as we see that the Dojo
    committers themselves that are working on mobile additions are not
    willing to rely on Dojo base anymore. dojox.mobile.scrollable has
    self-bootstrapping system so it can run without dojo, dojox.mobile
    includes custom builds of dojo.js and Uxebu created
    EmbedJS to avoid the excessive size of Dojo base and it's modules.

    For the past year various Dojo committers have played around with
    various different projects and ideas that might fit into Dojo 2.0.
    These divergent paths have been very helpful, and there has been some
    fantastic progress in modularizing, optimizing, and shrinking
    Dojo-esque/Dojo-future modules. However, I think we need to start being able to
    utilize this stuff for the mobile side of things sooner rather than
    later, and perhaps we need to start looking at picking some of these
    paths and converging our efforts for Dojo 2.0. Even if Dojo 2.0 is not
    right around the corner, the need for the improved, more modularized
    components many of you have been working is immediate. I think it is
    important that Dojo mobile developers (like dojox.mobile and Wink) can
    start using components from EmbedJS, Uber.js, has.js, etc. The most
    critical thing we need now for this to work is basic interoperability.
    We really need AMD and CommonJS packaging for these projects. One of
    the reason I wanted to get the package system out there is so people
    could easily share these projects and start building things that
    utilize modules from different ones.

    Of course in the short term we aren't going to drop 1.x tomorrow. But again by looking at 2.0 it will help shape our progress with 1.x. I think on of the most important short term need is for
    these to be AMD compatible and packaged so mobile developers can start
    depending on, require()ing, using them (not just within EmbedJS,
    other's own system). AMD helps decouple us from particular
    implementations and allows us to more freely build components on
    a variety of different base modules. We can also be more explicit on modules from base that we rely on (like "dojo/connect" for example), rather than always assuming the presence of base. This makes it much more feasible to create alternate builds of Dojo base and progress towards more a modular future in 2.0.

    Here are some the projects that have been tossed around. I wanted to
    give my thoughts on some the strong points from each of these that I
    think deserve extra focus and attention as on track for Dojo 2.0 and our progress towards it. Perhaps there is or should be a wiki page to start flushing this stuff
    out more. Anyway, as far as some good stuff out there, IMO:

    http://github.com/phiggins42/has.js - Yes, we should be using this for
    feature detection. After AMD conversion, this is the next most
    important convention to follow so can have consistent feature
    detection that can be handled by builds (creating different builds
    based on device/feature sets). RequireJS 0.22 now supports build-level
    handling of has() branches. Which is awesome.

    http://github.com/phiggins42/uber.js - Peter and Bryan have done some
    great working demonstrating how modules can be written using has()
    feature detection in this project. The "array", "string", and
    "function" modules are some great modules for demonstrating that.
    Bryan and I have also been talking about some strategies with events
    and AOP to minimize code size. Eugene had a great suggestion, that we
    should separate AOP and events. I'd like to clarify how I believe this
    delineation should be made. This is not DOM vs plain objects, but AOP
    vs events, non-DOM objects should be able to be event
    emitters/listeners as well. Along these lines, I have suggested that
    an event listening function should have a super light branch for
    standards-based addEventListener, and if not available (IE <9) then
    depend on (maximize reuse) AOP code for DOM0 event handling (and don't
    waste bytes on having attachEvent code). Also, I would like to have
    consistency in our static AOP functions that operate on existing
    objects and the AOP decorators I have suggested for use in class
    creation (see next project down). before/after/around should mean the
    same thing whether it be on an existing object or a superclass.
    The uber.js modules would need to be upgraded to AMD format to use in
    Dojo 2. Bryan said he was planning on doing that.

    http://github.com/kriszyp/compose - The is an OO class that I proposed
    as a replacement for dojo.declare. The documentation should explain
    it, but it is intended to be much lighter and is influenced by traits,
    mixins, AOP, and decorators. This uses AOP decorators to achieve super
    calls.

    http://github.com/uxebu/embedjs - This is an awesome effort, lot's of
    cool stuff has been done here. However, any EmbedJS stuff that goes
    into Dojo 2.0 needs to get upgraded to AMD module format. Some of the
    individual parts of EmbedJS that I'd specifically like to see Dojo 2:
    * query - Awesome, I totally love what uxebu has done with query,
    this is the way to go.
    * async - I like how the main promise module is light, and they only
    load the back-compat API if necessary, good work.
    * uri - yeah, objectToQuery should be broken out of xhr.
    * array - Users can choose whether or not to apply array extras to
    Array.prototype (by loading native). Smart way to go.
    And lots of other modularization that is great.

    https://github.com/blowery/dojo-on - I am definitely a fan of spelling
    our event registration function "on()", it is succinct, matches
    NodeJS, and reads well. I am definitely not a fan of requiring the
    callback to provided in a separate then() call. Simple three argument
    (node, eventType, listener) calls for registering event handlers is
    the bread and butter of apps and shouldn't be complicated. We could
    return a promise compatible object from on() calls, but we still need
    to support providing the listener in the initial call. However, that
    being said, I would like to the event registration handled by compose
    (see below) to reuse the same code for AOP, super calls, event
    registration, and pubsub.

    http://bdframework.org/docs/loader/loader.html - Yes, pretty sure we
    want to use this. We have put a lot of effort in getting ready for
    this. Of course we also want to have RequireJS compatibility as well.
    Rawld has done an awesome job replicating the important features of
    RequireJS with a lightweight Dojo-ready version.

    http://github.com/uhop/pulsar - Eugene has jotted down a lot of good
    ideas in the comments on these modules. Both Eugene and Uxebu have hit
    on the need to break up html/dom. It is far too big as a single
    module. The project also nicely demonstrates our future package layout

    http://github.com/unscriptable/cujo - Looks like John is doing some
    great stuff with MVC. We really need to get better data binding
    support, I think.

    Rahul demonstrating a great data-binding system as well. It would be
    great to be able to move forward with this.

    Ben Hockey has been looking into higher level framework infrastructure as well.

    Other modules to think about:

    - json - We should feature detect and branch, using native JSON if
    available.

    - jsonp - This is actually completely unneeded now because it is a
    subset of AMD. We could a put module somewhere if we need to catch
    people's attention, but RequireJS and Backdraft should be able to
    JSONP OOTB by virtue of their module loading capability.


    - Separating general CSS look and feel from component specific CSS
    layout. We discussed this in another thread, and I still think we need
    a more extensible and easier to use theming system, and the ability to
    declare CSS as a dependency so users don't have to manually do it.
    Dustin and I have been talking about this, based on problems in
    earlier versions of Dojo when this was attempted to some degree. Some
    of the issues:
    * Script ordering is very important, loading a CSS that might load
    another CSS which unexpectedly takes precedence over something that
    was trying to override it must be avoided. We can't support transitive
    dependencies that would allow this to take place.
    * IE has a 31 stylesheet limit. I think this can be overcome by
    aggregating stylesheets when the limit is hit.
    * This should be done as an AMD plugin. John Hann has some code that
    does this already: http://github.com/unscriptable/cssx
    * There are two ways to load CSS, via XHR and inserting the response
    as CSS into a stylesheet, or creating a stylesheet with a src that
    points to the CSS to be loaded. Loading using src attribute is
    probably faster and easier. XHR could allow us to do processing on the
    CSS (supporting variables at runtime, doing proactive CSS3
    adjustments), but it is problematic for cross-domain and requires
    adjusting relative urls to match the CSS source's path. I'd prefer to
    use src to keep things as small as possible.
    * Ideally a theme is nothing more than generic CSS class definitions
    that are agnostic and decoupled from specific widget implementations,
    but there are times when individual components may need extra
    theme-specific CSS. We may want our CSS plugin to support
    theme-specific branching. The key here is that new components should
    be able to have theme specific CSS without adding CSS to the theme
    directory, and one should be able to create a new theme without adding
    to the individual component directories.
    * Even if we decide that this may be overly painful to retrofit
    existing widgets, we can and should be considering applying this
    concepts with new widgets, particularly in the mobile space, where
    selective loading could really help us to minimize downloaded bytes.

    Another cool idea that I see people doing is providing backwards
    compatiblity shims for CSS3 usage. I think that is being done in
    dojox.mobile and John has worked on that here as well:
    http://github.com/unscriptable/cssx

    - lang.js type checking (is.js in EmbedJS) - Please, this atrocity can
    not see the light of day in Dojo 2.0. Using dojo.isString(value)
    instead typeof value == "string", is slower, increases the size of our
    library, and allows primitive wrappers to permeate code (timebombs
    that we should be trying to eliminate).

    Other related notes include our new object store API (although that is already in 1.6), and moving GFX/Charting directly into Dojo core.

    Also, here are some more thoughts on dojox.mobile itself.

    - HTML5 elements (particularly form elements) - We really need to have
    a parser that can scan HTML for new HTML5 elements and back-shim with
    our widgets when the current browser doesn't natively support them.
    For the most part, this actually should not be very difficult to do,
    it is basically a matter of looking for <input>'s, finding the ones
    with a "type" that the browser doesn't support, and instantiating them
    with any necessary mappings to make sure our attributes match html5's.
    I think the most challenging part of this could be if we want to do
    build integration that can branch for different platforms to include
    or not include the widgets that are necessary to back-shim (since the
    main point is to reduce code size with native components). This type
    of parser could be created at anytime (doesn't need to wait for 2.0 or
    anything).

    - I'd love to see some consistency with list/grid handling such that
    the mobile list widgets and the desktop grids could inherit from a
    common hierarchy such that all would support arrays, inline <li> or
    <tr>'s, or stores for input.

    - Helpers to assist to with device normalization. I would think that a
    true multi-device web application might be structured like:
    * iphone - Load simple list, use HTML5 form, use iphone.css, light
    mobile widgets, no accessibility (hopefully 20-30K)
    * android - Load simple list, use HTML5 form, use android.css, light
    mobile widgets, no accessibility (hopefully 20-30K)
    * Desktop Firefox (or other modern HTML5 browser) - Use multiple
    column grid, use claro.css, desktop widgets with accessibility (hopefully 50-100K)
    * IE - Load claro.css, desktop widgets, HTML5 shim widgets
    (DateTextBox, ValidationTextBox, etc.), memory-leak protection, (and
    anything else we can download to give them a slower more painful
    experience :) . (100 - 150K)

    I think there a lot we could do to help with branching and loading different CSS, and making easy to create builds for different platforms and run-time branching to them.

    Anyway, hopefully these thoughts could help organize our efforts and focus our various projects to coalesce towards mobile-ready Dojo awesomeness.

    --
    Thanks,
    Kris
  • Tom Trenka at Jan 10, 2011 at 8:05 pm
    I think something was goofy with Kris mailing this out, they are all
    basically the same.

    -- Tom
    On Mon, Jan 10, 2011 at 3:02 PM, Eugene Lazutkin wrote:

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Which one out of five is the most definitive one to read? This one? It
    looks the latest to me, but I may be wrong.

    Cheers,

    Eugene
    On 1/10/11 9:40 AM, Kris Zyp wrote:
    I wanted to throw out some more thoughts on Dojo future and 2.0 and
    mobile. I have previously advocated delaying 2.0 as long as possible and trying
    to evolve the 1.x codebase as much as possible. However, as the need
    for a mobile presence is continuing to rise, and looking at what is
    needed for Dojo to be the greatest mobile framework on the planet, I
    think it is increasingly evident that 1.x base is too big and in many
    situations is non-optimal as an assumed include for creating lightweight
    mobile web
    applications. This is painfully demonstrated as we see that the Dojo
    committers themselves that are working on mobile additions are not
    willing to rely on Dojo base anymore. dojox.mobile.scrollable has
    self-bootstrapping system so it can run without dojo, dojox.mobile
    includes custom builds of dojo.js and Uxebu created
    EmbedJS to avoid the excessive size of Dojo base and it's modules.

    For the past year various Dojo committers have played around with
    various different projects and ideas that might fit into Dojo 2.0.
    These divergent paths have been very helpful, and there has been some
    fantastic progress in modularizing, optimizing, and shrinking
    Dojo-esque/Dojo-future modules. However, I think we need to start being able to
    utilize this stuff for the mobile side of things sooner rather than
    later, and perhaps we need to start looking at picking some of these
    paths and converging our efforts for Dojo 2.0. Even if Dojo 2.0 is not
    right around the corner, the need for the improved, more modularized
    components many of you have been working is immediate. I think it is
    important that Dojo mobile developers (like dojox.mobile and Wink) can
    start using components from EmbedJS, Uber.js, has.js, etc. The most
    critical thing we need now for this to work is basic interoperability.
    We really need AMD and CommonJS packaging for these projects. One of
    the reason I wanted to get the package system out there is so people
    could easily share these projects and start building things that
    utilize modules from different ones.

    Of course in the short term we aren't going to drop 1.x tomorrow. But
    again by looking at 2.0 it will help shape our progress with 1.x. I think on
    of the most important short term need is for
    these to be AMD compatible and packaged so mobile developers can start
    depending on, require()ing, using them (not just within EmbedJS,
    other's own system). AMD helps decouple us from particular
    implementations and allows us to more freely build components on
    a variety of different base modules. We can also be more explicit on
    modules from base that we rely on (like "dojo/connect" for example), rather
    than always assuming the presence of base. This makes it much more feasible
    to create alternate builds of Dojo base and progress towards more a modular
    future in 2.0.
    Here are some the projects that have been tossed around. I wanted to
    give my thoughts on some the strong points from each of these that I
    think deserve extra focus and attention as on track for Dojo 2.0 and our
    progress towards it. Perhaps there is or should be a wiki page to start
    flushing this stuff
    out more. Anyway, as far as some good stuff out there, IMO:

    http://github.com/phiggins42/has.js - Yes, we should be using this for
    feature detection. After AMD conversion, this is the next most
    important convention to follow so can have consistent feature
    detection that can be handled by builds (creating different builds
    based on device/feature sets). RequireJS 0.22 now supports build-level
    handling of has() branches. Which is awesome.

    http://github.com/phiggins42/uber.js - Peter and Bryan have done some
    great working demonstrating how modules can be written using has()
    feature detection in this project. The "array", "string", and
    "function" modules are some great modules for demonstrating that.
    Bryan and I have also been talking about some strategies with events
    and AOP to minimize code size. Eugene had a great suggestion, that we
    should separate AOP and events. I'd like to clarify how I believe this
    delineation should be made. This is not DOM vs plain objects, but AOP
    vs events, non-DOM objects should be able to be event
    emitters/listeners as well. Along these lines, I have suggested that
    an event listening function should have a super light branch for
    standards-based addEventListener, and if not available (IE <9) then
    depend on (maximize reuse) AOP code for DOM0 event handling (and don't
    waste bytes on having attachEvent code). Also, I would like to have
    consistency in our static AOP functions that operate on existing
    objects and the AOP decorators I have suggested for use in class
    creation (see next project down). before/after/around should mean the
    same thing whether it be on an existing object or a superclass.
    The uber.js modules would need to be upgraded to AMD format to use in
    Dojo 2. Bryan said he was planning on doing that.

    http://github.com/kriszyp/compose - The is an OO class that I proposed
    as a replacement for dojo.declare. The documentation should explain
    it, but it is intended to be much lighter and is influenced by traits,
    mixins, AOP, and decorators. This uses AOP decorators to achieve super
    calls.

    http://github.com/uxebu/embedjs - This is an awesome effort, lot's of
    cool stuff has been done here. However, any EmbedJS stuff that goes
    into Dojo 2.0 needs to get upgraded to AMD module format. Some of the
    individual parts of EmbedJS that I'd specifically like to see Dojo 2:
    * query - Awesome, I totally love what uxebu has done with query,
    this is the way to go.
    * async - I like how the main promise module is light, and they only
    load the back-compat API if necessary, good work.
    * uri - yeah, objectToQuery should be broken out of xhr.
    * array - Users can choose whether or not to apply array extras to
    Array.prototype (by loading native). Smart way to go.
    And lots of other modularization that is great.

    https://github.com/blowery/dojo-on - I am definitely a fan of spelling
    our event registration function "on()", it is succinct, matches
    NodeJS, and reads well. I am definitely not a fan of requiring the
    callback to provided in a separate then() call. Simple three argument
    (node, eventType, listener) calls for registering event handlers is
    the bread and butter of apps and shouldn't be complicated. We could
    return a promise compatible object from on() calls, but we still need
    to support providing the listener in the initial call. However, that
    being said, I would like to the event registration handled by compose
    (see below) to reuse the same code for AOP, super calls, event
    registration, and pubsub.

    http://bdframework.org/docs/loader/loader.html - Yes, pretty sure we
    want to use this. We have put a lot of effort in getting ready for
    this. Of course we also want to have RequireJS compatibility as well.
    Rawld has done an awesome job replicating the important features of
    RequireJS with a lightweight Dojo-ready version.

    http://github.com/uhop/pulsar - Eugene has jotted down a lot of good
    ideas in the comments on these modules. Both Eugene and Uxebu have hit
    on the need to break up html/dom. It is far too big as a single
    module. The project also nicely demonstrates our future package layout

    http://github.com/unscriptable/cujo - Looks like John is doing some
    great stuff with MVC. We really need to get better data binding
    support, I think.

    Rahul demonstrating a great data-binding system as well. It would be
    great to be able to move forward with this.

    Ben Hockey has been looking into higher level framework infrastructure as well.
    Other modules to think about:

    - json - We should feature detect and branch, using native JSON if
    available.

    - jsonp - This is actually completely unneeded now because it is a
    subset of AMD. We could a put module somewhere if we need to catch
    people's attention, but RequireJS and Backdraft should be able to
    JSONP OOTB by virtue of their module loading capability.


    - Separating general CSS look and feel from component specific CSS
    layout. We discussed this in another thread, and I still think we need
    a more extensible and easier to use theming system, and the ability to
    declare CSS as a dependency so users don't have to manually do it.
    Dustin and I have been talking about this, based on problems in
    earlier versions of Dojo when this was attempted to some degree. Some
    of the issues:
    * Script ordering is very important, loading a CSS that might load
    another CSS which unexpectedly takes precedence over something that
    was trying to override it must be avoided. We can't support transitive
    dependencies that would allow this to take place.
    * IE has a 31 stylesheet limit. I think this can be overcome by
    aggregating stylesheets when the limit is hit.
    * This should be done as an AMD plugin. John Hann has some code that
    does this already: http://github.com/unscriptable/cssx
    * There are two ways to load CSS, via XHR and inserting the response
    as CSS into a stylesheet, or creating a stylesheet with a src that
    points to the CSS to be loaded. Loading using src attribute is
    probably faster and easier. XHR could allow us to do processing on the
    CSS (supporting variables at runtime, doing proactive CSS3
    adjustments), but it is problematic for cross-domain and requires
    adjusting relative urls to match the CSS source's path. I'd prefer to
    use src to keep things as small as possible.
    * Ideally a theme is nothing more than generic CSS class definitions
    that are agnostic and decoupled from specific widget implementations,
    but there are times when individual components may need extra
    theme-specific CSS. We may want our CSS plugin to support
    theme-specific branching. The key here is that new components should
    be able to have theme specific CSS without adding CSS to the theme
    directory, and one should be able to create a new theme without adding
    to the individual component directories.
    * Even if we decide that this may be overly painful to retrofit
    existing widgets, we can and should be considering applying this
    concepts with new widgets, particularly in the mobile space, where
    selective loading could really help us to minimize downloaded bytes.

    Another cool idea that I see people doing is providing backwards
    compatiblity shims for CSS3 usage. I think that is being done in
    dojox.mobile and John has worked on that here as well:
    http://github.com/unscriptable/cssx

    - lang.js type checking (is.js in EmbedJS) - Please, this atrocity can
    not see the light of day in Dojo 2.0. Using dojo.isString(value)
    instead typeof value == "string", is slower, increases the size of our
    library, and allows primitive wrappers to permeate code (timebombs
    that we should be trying to eliminate).

    Other related notes include our new object store API (although that is
    already in 1.6), and moving GFX/Charting directly into Dojo core.
    Also, here are some more thoughts on dojox.mobile itself.

    - HTML5 elements (particularly form elements) - We really need to have
    a parser that can scan HTML for new HTML5 elements and back-shim with
    our widgets when the current browser doesn't natively support them.
    For the most part, this actually should not be very difficult to do,
    it is basically a matter of looking for <input>'s, finding the ones
    with a "type" that the browser doesn't support, and instantiating them
    with any necessary mappings to make sure our attributes match html5's.
    I think the most challenging part of this could be if we want to do
    build integration that can branch for different platforms to include
    or not include the widgets that are necessary to back-shim (since the
    main point is to reduce code size with native components). This type
    of parser could be created at anytime (doesn't need to wait for 2.0 or
    anything).

    - I'd love to see some consistency with list/grid handling such that
    the mobile list widgets and the desktop grids could inherit from a
    common hierarchy such that all would support arrays, inline <li> or
    <tr>'s, or stores for input.

    - Helpers to assist to with device normalization. I would think that a
    true multi-device web application might be structured like:
    * iphone - Load simple list, use HTML5 form, use iphone.css, light
    mobile widgets, no accessibility (hopefully 20-30K)
    * android - Load simple list, use HTML5 form, use android.css, light
    mobile widgets, no accessibility (hopefully 20-30K)
    * Desktop Firefox (or other modern HTML5 browser) - Use multiple
    column grid, use claro.css, desktop widgets with accessibility (hopefully 50-100K)
    * IE - Load claro.css, desktop widgets, HTML5 shim widgets
    (DateTextBox, ValidationTextBox, etc.), memory-leak protection, (and
    anything else we can download to give them a slower more painful
    experience :) . (100 - 150K)

    I think there a lot we could do to help with branching and loading
    different CSS, and making easy to create builds for different platforms and
    run-time branching to them.
    Anyway, hopefully these thoughts could help organize our efforts and
    focus our various projects to coalesce towards mobile-ready Dojo
    awesomeness.
    --
    Thanks,
    Kris
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.11 (Darwin)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

    iEYEARECAAYFAk0rc9wACgkQY214tZwSfCvOOwCgpxjJWOJaim6g+oknCj6IN0Zi
    9DkAoIvyCn7BVZfJHk9fA9QUaOGvI0hZ
    =psi3
    -----END PGP SIGNATURE-----
    _______________________________________________
    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/20110110/735d225c/attachment-0001.html
  • Tom Trenka at Jan 11, 2011 at 12:11 pm
    ...hearing crickets...

    I'll throw in my two cents, for what it's worth...I agree with everything
    Kris is proposing here, and understand that this is a large undertaking but
    needs to be done. We'll need to figure out and make sure everyone
    understands some logistical things, such as:

    1. Where would this be developed? Would we make the move to GitHub to
    begin this effort, or would we try to do a branch in our own SVN repository
    first?

    2. If we move to GitHub, where do we do it? We already have group accounts
    for DTK (not many people have asked for access), but we're also maintaining
    (mostly Eugene) a clone of the current SVN repo.

    3. We'll need to get people set up with how to develop using RequireJS (and
    probably ComposeJS) sooner than later; I know many of us (myself included)
    probably haven't tried using either yet. Probably get people up to speed
    using GitHub as well (I use it but I'm definitely a beginner when it comes
    to it).

    Piggy-backing on Kris' thoughts, the one thing I would stress is that we
    *must* make sure the Dojo 2.0 branch is as absolutely as lean and mean as
    possible. Using has.js with some build tool adjustments (which I believe
    James has already done) should result in builds that strip out feature
    forks; I'm not entirely sure that's the case at the moment, can anyone
    confirm? We probably should be creating platform-specific profiles as well,
    aimed at creating builds that are as small as absolutely possible.

    I will continue to think about this and post more thoughts as I go. Anyone
    else want to chime in?

    Regards,
    Tom



    On Mon, Jan 10, 2011 at 7:05 PM, Tom Trenka wrote:

    I think something was goofy with Kris mailing this out, they are all
    basically the same.

    -- Tom

    On Mon, Jan 10, 2011 at 3:02 PM, Eugene Lazutkin wrote:

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Which one out of five is the most definitive one to read? This one? It
    looks the latest to me, but I may be wrong.

    Cheers,

    Eugene
    On 1/10/11 9:40 AM, Kris Zyp wrote:
    I wanted to throw out some more thoughts on Dojo future and 2.0 and
    mobile. I have previously advocated delaying 2.0 as long as possible and trying
    to evolve the 1.x codebase as much as possible. However, as the need
    for a mobile presence is continuing to rise, and looking at what is
    needed for Dojo to be the greatest mobile framework on the planet, I
    think it is increasingly evident that 1.x base is too big and in many
    situations is non-optimal as an assumed include for creating lightweight
    mobile web
    applications. This is painfully demonstrated as we see that the Dojo
    committers themselves that are working on mobile additions are not
    willing to rely on Dojo base anymore. dojox.mobile.scrollable has
    self-bootstrapping system so it can run without dojo, dojox.mobile
    includes custom builds of dojo.js and Uxebu created
    EmbedJS to avoid the excessive size of Dojo base and it's modules.

    For the past year various Dojo committers have played around with
    various different projects and ideas that might fit into Dojo 2.0.
    These divergent paths have been very helpful, and there has been some
    fantastic progress in modularizing, optimizing, and shrinking
    Dojo-esque/Dojo-future modules. However, I think we need to start being able to
    utilize this stuff for the mobile side of things sooner rather than
    later, and perhaps we need to start looking at picking some of these
    paths and converging our efforts for Dojo 2.0. Even if Dojo 2.0 is not
    right around the corner, the need for the improved, more modularized
    components many of you have been working is immediate. I think it is
    important that Dojo mobile developers (like dojox.mobile and Wink) can
    start using components from EmbedJS, Uber.js, has.js, etc. The most
    critical thing we need now for this to work is basic interoperability.
    We really need AMD and CommonJS packaging for these projects. One of
    the reason I wanted to get the package system out there is so people
    could easily share these projects and start building things that
    utilize modules from different ones.

    Of course in the short term we aren't going to drop 1.x tomorrow. But
    again by looking at 2.0 it will help shape our progress with 1.x. I think on
    of the most important short term need is for
    these to be AMD compatible and packaged so mobile developers can start
    depending on, require()ing, using them (not just within EmbedJS,
    other's own system). AMD helps decouple us from particular
    implementations and allows us to more freely build components on
    a variety of different base modules. We can also be more explicit on
    modules from base that we rely on (like "dojo/connect" for example), rather
    than always assuming the presence of base. This makes it much more feasible
    to create alternate builds of Dojo base and progress towards more a modular
    future in 2.0.
    Here are some the projects that have been tossed around. I wanted to
    give my thoughts on some the strong points from each of these that I
    think deserve extra focus and attention as on track for Dojo 2.0 and our
    progress towards it. Perhaps there is or should be a wiki page to start
    flushing this stuff
    out more. Anyway, as far as some good stuff out there, IMO:

    http://github.com/phiggins42/has.js - Yes, we should be using this for
    feature detection. After AMD conversion, this is the next most
    important convention to follow so can have consistent feature
    detection that can be handled by builds (creating different builds
    based on device/feature sets). RequireJS 0.22 now supports build-level
    handling of has() branches. Which is awesome.

    http://github.com/phiggins42/uber.js - Peter and Bryan have done some
    great working demonstrating how modules can be written using has()
    feature detection in this project. The "array", "string", and
    "function" modules are some great modules for demonstrating that.
    Bryan and I have also been talking about some strategies with events
    and AOP to minimize code size. Eugene had a great suggestion, that we
    should separate AOP and events. I'd like to clarify how I believe this
    delineation should be made. This is not DOM vs plain objects, but AOP
    vs events, non-DOM objects should be able to be event
    emitters/listeners as well. Along these lines, I have suggested that
    an event listening function should have a super light branch for
    standards-based addEventListener, and if not available (IE <9) then
    depend on (maximize reuse) AOP code for DOM0 event handling (and don't
    waste bytes on having attachEvent code). Also, I would like to have
    consistency in our static AOP functions that operate on existing
    objects and the AOP decorators I have suggested for use in class
    creation (see next project down). before/after/around should mean the
    same thing whether it be on an existing object or a superclass.
    The uber.js modules would need to be upgraded to AMD format to use in
    Dojo 2. Bryan said he was planning on doing that.

    http://github.com/kriszyp/compose - The is an OO class that I proposed
    as a replacement for dojo.declare. The documentation should explain
    it, but it is intended to be much lighter and is influenced by traits,
    mixins, AOP, and decorators. This uses AOP decorators to achieve super
    calls.

    http://github.com/uxebu/embedjs - This is an awesome effort, lot's of
    cool stuff has been done here. However, any EmbedJS stuff that goes
    into Dojo 2.0 needs to get upgraded to AMD module format. Some of the
    individual parts of EmbedJS that I'd specifically like to see Dojo 2:
    * query - Awesome, I totally love what uxebu has done with query,
    this is the way to go.
    * async - I like how the main promise module is light, and they only
    load the back-compat API if necessary, good work.
    * uri - yeah, objectToQuery should be broken out of xhr.
    * array - Users can choose whether or not to apply array extras to
    Array.prototype (by loading native). Smart way to go.
    And lots of other modularization that is great.

    https://github.com/blowery/dojo-on - I am definitely a fan of spelling
    our event registration function "on()", it is succinct, matches
    NodeJS, and reads well. I am definitely not a fan of requiring the
    callback to provided in a separate then() call. Simple three argument
    (node, eventType, listener) calls for registering event handlers is
    the bread and butter of apps and shouldn't be complicated. We could
    return a promise compatible object from on() calls, but we still need
    to support providing the listener in the initial call. However, that
    being said, I would like to the event registration handled by compose
    (see below) to reuse the same code for AOP, super calls, event
    registration, and pubsub.

    http://bdframework.org/docs/loader/loader.html - Yes, pretty sure we
    want to use this. We have put a lot of effort in getting ready for
    this. Of course we also want to have RequireJS compatibility as well.
    Rawld has done an awesome job replicating the important features of
    RequireJS with a lightweight Dojo-ready version.

    http://github.com/uhop/pulsar - Eugene has jotted down a lot of good
    ideas in the comments on these modules. Both Eugene and Uxebu have hit
    on the need to break up html/dom. It is far too big as a single
    module. The project also nicely demonstrates our future package layout

    http://github.com/unscriptable/cujo - Looks like John is doing some
    great stuff with MVC. We really need to get better data binding
    support, I think.

    Rahul demonstrating a great data-binding system as well. It would be
    great to be able to move forward with this.

    Ben Hockey has been looking into higher level framework infrastructure as well.
    Other modules to think about:

    - json - We should feature detect and branch, using native JSON if
    available.

    - jsonp - This is actually completely unneeded now because it is a
    subset of AMD. We could a put module somewhere if we need to catch
    people's attention, but RequireJS and Backdraft should be able to
    JSONP OOTB by virtue of their module loading capability.


    - Separating general CSS look and feel from component specific CSS
    layout. We discussed this in another thread, and I still think we need
    a more extensible and easier to use theming system, and the ability to
    declare CSS as a dependency so users don't have to manually do it.
    Dustin and I have been talking about this, based on problems in
    earlier versions of Dojo when this was attempted to some degree. Some
    of the issues:
    * Script ordering is very important, loading a CSS that might load
    another CSS which unexpectedly takes precedence over something that
    was trying to override it must be avoided. We can't support transitive
    dependencies that would allow this to take place.
    * IE has a 31 stylesheet limit. I think this can be overcome by
    aggregating stylesheets when the limit is hit.
    * This should be done as an AMD plugin. John Hann has some code that
    does this already: http://github.com/unscriptable/cssx
    * There are two ways to load CSS, via XHR and inserting the response
    as CSS into a stylesheet, or creating a stylesheet with a src that
    points to the CSS to be loaded. Loading using src attribute is
    probably faster and easier. XHR could allow us to do processing on the
    CSS (supporting variables at runtime, doing proactive CSS3
    adjustments), but it is problematic for cross-domain and requires
    adjusting relative urls to match the CSS source's path. I'd prefer to
    use src to keep things as small as possible.
    * Ideally a theme is nothing more than generic CSS class definitions
    that are agnostic and decoupled from specific widget implementations,
    but there are times when individual components may need extra
    theme-specific CSS. We may want our CSS plugin to support
    theme-specific branching. The key here is that new components should
    be able to have theme specific CSS without adding CSS to the theme
    directory, and one should be able to create a new theme without adding
    to the individual component directories.
    * Even if we decide that this may be overly painful to retrofit
    existing widgets, we can and should be considering applying this
    concepts with new widgets, particularly in the mobile space, where
    selective loading could really help us to minimize downloaded bytes.

    Another cool idea that I see people doing is providing backwards
    compatiblity shims for CSS3 usage. I think that is being done in
    dojox.mobile and John has worked on that here as well:
    http://github.com/unscriptable/cssx

    - lang.js type checking (is.js in EmbedJS) - Please, this atrocity can
    not see the light of day in Dojo 2.0. Using dojo.isString(value)
    instead typeof value == "string", is slower, increases the size of our
    library, and allows primitive wrappers to permeate code (timebombs
    that we should be trying to eliminate).

    Other related notes include our new object store API (although that is
    already in 1.6), and moving GFX/Charting directly into Dojo core.
    Also, here are some more thoughts on dojox.mobile itself.

    - HTML5 elements (particularly form elements) - We really need to have
    a parser that can scan HTML for new HTML5 elements and back-shim with
    our widgets when the current browser doesn't natively support them.
    For the most part, this actually should not be very difficult to do,
    it is basically a matter of looking for <input>'s, finding the ones
    with a "type" that the browser doesn't support, and instantiating them
    with any necessary mappings to make sure our attributes match html5's.
    I think the most challenging part of this could be if we want to do
    build integration that can branch for different platforms to include
    or not include the widgets that are necessary to back-shim (since the
    main point is to reduce code size with native components). This type
    of parser could be created at anytime (doesn't need to wait for 2.0 or
    anything).

    - I'd love to see some consistency with list/grid handling such that
    the mobile list widgets and the desktop grids could inherit from a
    common hierarchy such that all would support arrays, inline <li> or
    <tr>'s, or stores for input.

    - Helpers to assist to with device normalization. I would think that a
    true multi-device web application might be structured like:
    * iphone - Load simple list, use HTML5 form, use iphone.css, light
    mobile widgets, no accessibility (hopefully 20-30K)
    * android - Load simple list, use HTML5 form, use android.css, light
    mobile widgets, no accessibility (hopefully 20-30K)
    * Desktop Firefox (or other modern HTML5 browser) - Use multiple
    column grid, use claro.css, desktop widgets with accessibility
    (hopefully 50-100K)
    * IE - Load claro.css, desktop widgets, HTML5 shim widgets
    (DateTextBox, ValidationTextBox, etc.), memory-leak protection, (and
    anything else we can download to give them a slower more painful
    experience :) . (100 - 150K)

    I think there a lot we could do to help with branching and loading
    different CSS, and making easy to create builds for different platforms and
    run-time branching to them.
    Anyway, hopefully these thoughts could help organize our efforts and
    focus our various projects to coalesce towards mobile-ready Dojo
    awesomeness.
    --
    Thanks,
    Kris
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.11 (Darwin)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

    iEYEARECAAYFAk0rc9wACgkQY214tZwSfCvOOwCgpxjJWOJaim6g+oknCj6IN0Zi
    9DkAoIvyCn7BVZfJHk9fA9QUaOGvI0hZ
    =psi3
    -----END PGP SIGNATURE-----
    _______________________________________________
    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/20110111/4af48ab9/attachment-0001.htm
  • Eugene Lazutkin at Jan 10, 2011 at 8:31 pm
    I've read Kris' post in this thread. I think he reiterated very
    important points.

    In particular I think it should be stupidly easy to create subsets of
    everything, including the base/kernel. In my opinion we should provide
    three "standard" profiles for the kernel: one suitable for mobile (a
    micro-nucleus, if you wish), one suitable for the desktop (similar to
    what we have now), and one suitable for server-side platforms.
    Everything in between should be covered by custom builds.

    If we don't provide "common points" it'll be hard to talk about Dojo
    kernel at all, and hard to evaluate if other projects can be used with
    this particular kernel. Additionally it gives kernel baselines, which
    can be targeted by authors of other modules.

    Last year I worked on an embedded project myself, specifically on
    Samsung TV widgets. Yes, the developer experience is very specific --- I
    saw limitations where I didn't expect any, e.g., in how XHR requests are
    queued and executed, or how dojo.query() is completely broken on this
    platform. On the other hand, every new generation of mobile platforms is
    closer to the desktop than the previous one. So at some point the
    separation between mobile/desktop tools can become a moot point. It is
    not there yet, but who knows what we will see in 2012-2013.

    Having said that, one difference between mobile/desktop is obvious and
    it is not going to go away with new hardware: UI. Smaller screen sizes,
    unusual formats, alternative or unusual input methods, and so on, will
    be as important as they are today. So in my opinion desktop/mobile UI is
    the area we should put much more efforts.

    Another area, which deserves more involvement form us, is web
    application helpers --- how to organize a web application using Dojo. It
    is clear that there is no such thing as a "universal" web app framework,
    which will solve all problems at once. There are many ways to organize a
    web app. IMHO, we should provide solutions for most common web apps,
    starting from mobile web apps, which use a relatively small number of
    variations.

    Talking to multiple institutional users I've following repeated requests:

    1) Light-weight easy-to-use tables/grids.

    2) Light-weight easy-to-use charts.

    3) Move a number of things to the Core (I don't know what it means
    exactly in the brave new world). Most common requests: graphics, and
    _Widget.js to complement our parser, which is in the Core already.

    Interesting note: because #1 and #2 above frequently occupy the whole
    screen on mobile platforms, we have to come up with ... UI for that. It
    is already started by IBM guys, but we have to be more involved with it.

    Regarding Pulsar. At DDD 2010 I promised to have something to show by
    1/31/2011 --- the idea is to have something working that can be
    criticized, tweaked, improved, benchmarked, and so on. I intend to honor
    this deadline --- I cleared up my schedule starting from 1/15/2011, to
    spend 2 weeks working on it more or less uninterrupted. If anybody wants
    to chip in (some of you already wrote to me asking), you are welcome!
    Next week I plan to publish a list of areas I need help with (conceptual
    areas, not boring coding). Stay tuned!

    I was sure at DDD and I am 100% sure now that the most important part of
    the "new deal" will be loaders, packages, and "web stores" / package
    repositories. I am pleased to see that we have something now, but I
    don't think it is mature enough. Even the package format is not fixed yet.

    Related question: are we going to identify any packages as "Dojo"? Are
    we going to have "Dojo Approved" program? Are we going to protect Dojo
    identity, and if yes --- how? What is our future Google/AOL CDN story?
    (The same goes for any other JavaScript library.)

    Cheers,

    Eugene Lazutkin
    http://lazutkin.com/

    On 01/10/2011 03:02 PM, Eugene Lazutkin wrote:
    Which one out of five is the most definitive one to read? This one? It
    looks the latest to me, but I may be wrong.

    Cheers,

    Eugene
    On 1/10/11 9:40 AM, Kris Zyp wrote:
    I wanted to throw out some more thoughts on Dojo future and 2.0 and
    mobile. I have previously advocated delaying 2.0 as long as possible and trying
    to evolve the 1.x codebase as much as possible. However, as the need
    for a mobile presence is continuing to rise, and looking at what is
    needed for Dojo to be the greatest mobile framework on the planet, I
    think it is increasingly evident that 1.x base is too big and in many
    situations is non-optimal as an assumed include for creating lightweight mobile web
    applications. This is painfully demonstrated as we see that the Dojo
    committers themselves that are working on mobile additions are not
    willing to rely on Dojo base anymore. dojox.mobile.scrollable has
    self-bootstrapping system so it can run without dojo, dojox.mobile
    includes custom builds of dojo.js and Uxebu created
    EmbedJS to avoid the excessive size of Dojo base and it's modules.
    For the past year various Dojo committers have played around with
    various different projects and ideas that might fit into Dojo 2.0.
    These divergent paths have been very helpful, and there has been some
    fantastic progress in modularizing, optimizing, and shrinking
    Dojo-esque/Dojo-future modules. However, I think we need to start being able to
    utilize this stuff for the mobile side of things sooner rather than
    later, and perhaps we need to start looking at picking some of these
    paths and converging our efforts for Dojo 2.0. Even if Dojo 2.0 is not
    right around the corner, the need for the improved, more modularized
    components many of you have been working is immediate. I think it is
    important that Dojo mobile developers (like dojox.mobile and Wink) can
    start using components from EmbedJS, Uber.js, has.js, etc. The most
    critical thing we need now for this to work is basic interoperability.
    We really need AMD and CommonJS packaging for these projects. One of
    the reason I wanted to get the package system out there is so people
    could easily share these projects and start building things that
    utilize modules from different ones.
    Of course in the short term we aren't going to drop 1.x tomorrow. But again by looking at 2.0 it will help shape our progress with 1.x. I think on of the most important short term need is for
    these to be AMD compatible and packaged so mobile developers can start
    depending on, require()ing, using them (not just within EmbedJS,
    other's own system). AMD helps decouple us from particular
    implementations and allows us to more freely build components on
    a variety of different base modules. We can also be more explicit on modules from base that we rely on (like "dojo/connect" for example), rather than always assuming the presence of base. This makes it much more feasible to create alternate builds of Dojo base and progress towards more a modular future in 2.0.
    Here are some the projects that have been tossed around. I wanted to
    give my thoughts on some the strong points from each of these that I
    think deserve extra focus and attention as on track for Dojo 2.0 and our progress towards it. Perhaps there is or should be a wiki page to start flushing this stuff
    out more. Anyway, as far as some good stuff out there, IMO:
    http://github.com/phiggins42/has.js - Yes, we should be using this for
    feature detection. After AMD conversion, this is the next most
    important convention to follow so can have consistent feature
    detection that can be handled by builds (creating different builds
    based on device/feature sets). RequireJS 0.22 now supports build-level
    handling of has() branches. Which is awesome.
    http://github.com/phiggins42/uber.js - Peter and Bryan have done some
    great working demonstrating how modules can be written using has()
    feature detection in this project. The "array", "string", and
    "function" modules are some great modules for demonstrating that.
    Bryan and I have also been talking about some strategies with events
    and AOP to minimize code size. Eugene had a great suggestion, that we
    should separate AOP and events. I'd like to clarify how I believe this
    delineation should be made. This is not DOM vs plain objects, but AOP
    vs events, non-DOM objects should be able to be event
    emitters/listeners as well. Along these lines, I have suggested that
    an event listening function should have a super light branch for
    standards-based addEventListener, and if not available (IE <9) then
    depend on (maximize reuse) AOP code for DOM0 event handling (and don't
    waste bytes on having attachEvent code). Also, I would like to have
    consistency in our static AOP functions that operate on existing
    objects and the AOP decorators I have suggested for use in class
    creation (see next project down). before/after/around should mean the
    same thing whether it be on an existing object or a superclass.
    The uber.js modules would need to be upgraded to AMD format to use in
    Dojo 2. Bryan said he was planning on doing that.
    http://github.com/kriszyp/compose - The is an OO class that I proposed
    as a replacement for dojo.declare. The documentation should explain
    it, but it is intended to be much lighter and is influenced by traits,
    mixins, AOP, and decorators. This uses AOP decorators to achieve super
    calls.
    http://github.com/uxebu/embedjs - This is an awesome effort, lot's of
    cool stuff has been done here. However, any EmbedJS stuff that goes
    into Dojo 2.0 needs to get upgraded to AMD module format. Some of the
    individual parts of EmbedJS that I'd specifically like to see Dojo 2:
    * query - Awesome, I totally love what uxebu has done with query,
    this is the way to go.
    * async - I like how the main promise module is light, and they only
    load the back-compat API if necessary, good work.
    * uri - yeah, objectToQuery should be broken out of xhr.
    * array - Users can choose whether or not to apply array extras to
    Array.prototype (by loading native). Smart way to go.
    And lots of other modularization that is great.
    https://github.com/blowery/dojo-on - I am definitely a fan of spelling
    our event registration function "on()", it is succinct, matches
    NodeJS, and reads well. I am definitely not a fan of requiring the
    callback to provided in a separate then() call. Simple three argument
    (node, eventType, listener) calls for registering event handlers is
    the bread and butter of apps and shouldn't be complicated. We could
    return a promise compatible object from on() calls, but we still need
    to support providing the listener in the initial call. However, that
    being said, I would like to the event registration handled by compose
    (see below) to reuse the same code for AOP, super calls, event
    registration, and pubsub.
    http://bdframework.org/docs/loader/loader.html - Yes, pretty sure we
    want to use this. We have put a lot of effort in getting ready for
    this. Of course we also want to have RequireJS compatibility as well.
    Rawld has done an awesome job replicating the important features of
    RequireJS with a lightweight Dojo-ready version.
    http://github.com/uhop/pulsar - Eugene has jotted down a lot of good
    ideas in the comments on these modules. Both Eugene and Uxebu have hit
    on the need to break up html/dom. It is far too big as a single
    module. The project also nicely demonstrates our future package layout
    http://github.com/unscriptable/cujo - Looks like John is doing some
    great stuff with MVC. We really need to get better data binding
    support, I think.
    Rahul demonstrating a great data-binding system as well. It would be
    great to be able to move forward with this.
    Ben Hockey has been looking into higher level framework infrastructure as well.
    Other modules to think about:
    - json - We should feature detect and branch, using native JSON if
    available.
    - jsonp - This is actually completely unneeded now because it is a
    subset of AMD. We could a put module somewhere if we need to catch
    people's attention, but RequireJS and Backdraft should be able to
    JSONP OOTB by virtue of their module loading capability.
    - Separating general CSS look and feel from component specific CSS
    layout. We discussed this in another thread, and I still think we need
    a more extensible and easier to use theming system, and the ability to
    declare CSS as a dependency so users don't have to manually do it.
    Dustin and I have been talking about this, based on problems in
    earlier versions of Dojo when this was attempted to some degree. Some
    of the issues:
    * Script ordering is very important, loading a CSS that might load
    another CSS which unexpectedly takes precedence over something that
    was trying to override it must be avoided. We can't support transitive
    dependencies that would allow this to take place.
    * IE has a 31 stylesheet limit. I think this can be overcome by
    aggregating stylesheets when the limit is hit.
    * This should be done as an AMD plugin. John Hann has some code that
    does this already: http://github.com/unscriptable/cssx
    * There are two ways to load CSS, via XHR and inserting the response
    as CSS into a stylesheet, or creating a stylesheet with a src that
    points to the CSS to be loaded. Loading using src attribute is
    probably faster and easier. XHR could allow us to do processing on the
    CSS (supporting variables at runtime, doing proactive CSS3
    adjustments), but it is problematic for cross-domain and requires
    adjusting relative urls to match the CSS source's path. I'd prefer to
    use src to keep things as small as possible.
    * Ideally a theme is nothing more than generic CSS class definitions
    that are agnostic and decoupled from specific widget implementations,
    but there are times when individual components may need extra
    theme-specific CSS. We may want our CSS plugin to support
    theme-specific branching. The key here is that new components should
    be able to have theme specific CSS without adding CSS to the theme
    directory, and one should be able to create a new theme without adding
    to the individual component directories.
    * Even if we decide that this may be overly painful to retrofit
    existing widgets, we can and should be considering applying this
    concepts with new widgets, particularly in the mobile space, where
    selective loading could really help us to minimize downloaded bytes.
    Another cool idea that I see people doing is providing backwards
    compatiblity shims for CSS3 usage. I think that is being done in
    dojox.mobile and John has worked on that here as well:
    http://github.com/unscriptable/cssx
    - lang.js type checking (is.js in EmbedJS) - Please, this atrocity can
    not see the light of day in Dojo 2.0. Using dojo.isString(value)
    instead typeof value == "string", is slower, increases the size of our
    library, and allows primitive wrappers to permeate code (timebombs
    that we should be trying to eliminate).
    Other related notes include our new object store API (although that is already in 1.6), and moving GFX/Charting directly into Dojo core.
    Also, here are some more thoughts on dojox.mobile itself.
    - HTML5 elements (particularly form elements) - We really need to have
    a parser that can scan HTML for new HTML5 elements and back-shim with
    our widgets when the current browser doesn't natively support them.
    For the most part, this actually should not be very difficult to do,
    it is basically a matter of looking for <input>'s, finding the ones
    with a "type" that the browser doesn't support, and instantiating them
    with any necessary mappings to make sure our attributes match html5's.
    I think the most challenging part of this could be if we want to do
    build integration that can branch for different platforms to include
    or not include the widgets that are necessary to back-shim (since the
    main point is to reduce code size with native components). This type
    of parser could be created at anytime (doesn't need to wait for 2.0 or
    anything).
    - I'd love to see some consistency with list/grid handling such that
    the mobile list widgets and the desktop grids could inherit from a
    common hierarchy such that all would support arrays, inline <li> or
    <tr>'s, or stores for input.
    - Helpers to assist to with device normalization. I would think that a
    true multi-device web application might be structured like:
    * iphone - Load simple list, use HTML5 form, use iphone.css, light
    mobile widgets, no accessibility (hopefully 20-30K)
    * android - Load simple list, use HTML5 form, use android.css, light
    mobile widgets, no accessibility (hopefully 20-30K)
    * Desktop Firefox (or other modern HTML5 browser) - Use multiple
    column grid, use claro.css, desktop widgets with accessibility (hopefully 50-100K)
    * IE - Load claro.css, desktop widgets, HTML5 shim widgets
    (DateTextBox, ValidationTextBox, etc.), memory-leak protection, (and
    anything else we can download to give them a slower more painful
    experience :) . (100 - 150K)
    I think there a lot we could do to help with branching and loading different CSS, and making easy to create builds for different platforms and run-time branching to them.
    Anyway, hopefully these thoughts could help organize our efforts and focus our various projects to coalesce towards mobile-ready Dojo awesomeness.
    --
    Thanks,
    Kris
  • Rawld Gill at Jan 12, 2011 at 2:08 pm

    On Monday 10 January 2011 17:31:07 Eugene Lazutkin wrote:
    I've read Kris' post in this thread. I think he reiterated very
    important points.

    In particular I think it should be stupidly easy to create subsets of
    everything, including the base/kernel.
    Seems like we all agree this is a key requirement.
    If we don't provide "common points" it'll be hard to talk about Dojo
    kernel at all, and hard to evaluate if other projects can be used with
    this particular kernel. Additionally it gives kernel baselines, which
    can be targeted by authors of other modules.
    Right. Also we loose brand without "common points". We must always keep the
    "what about marketing" question in mind.

    [snip]
    Another area, which deserves more involvement form us, is web
    application helpers --- how to organize a web application using Dojo. It
    is clear that there is no such thing as a "universal" web app framework,
    which will solve all problems at once. There are many ways to organize a
    web app. IMHO, we should provide solutions for most common web apps,
    starting from mobile web apps, which use a relatively small number of
    variations.

    Talking to multiple institutional users I've following repeated requests:

    1) Light-weight easy-to-use tables/grids.

    2) Light-weight easy-to-use charts.

    3) Move a number of things to the Core (I don't know what it means
    exactly in the brave new world). Most common requests: graphics, and
    _Widget.js to complement our parser, which is in the Core already.
    If you look at dijit, it has about a 10 key modules (dijit/_base/* and
    dijit/_widget) and then a bunch of widgets. Further, there are already some
    weird loading interdependencies in some of these modules (e.g.,
    dijit.wai.onload in dojo.parser). I've never understood why these 10 modules
    were separate from dojo. Put another way, e.g., are the 11 dojo/data modules
    any more/less related to dojo/base than these 10 modules? What's the common
    factor?

    To me, it seems like all of these should go into the dojo package. Each
    reasonably contiguous widget set should go into its own package. Remember, to
    say a module is a member of a package *does not imply* that module is
    automatically loaded when the package main is loaded.
    Interesting note: because #1 and #2 above frequently occupy the whole
    screen on mobile platforms, we have to come up with ... UI for that. It
    is already started by IBM guys, but we have to be more involved with it.
    One solution is apps with zero html. This has quite a few advantages. I think
    dojo must support this. And requiring the parser is not supporting this idea.
    But this is probably another long discussion for another time.
    Regarding Pulsar. At DDD 2010 I promised to have something to show by
    1/31/2011 --- the idea is to have something working that can be
    criticized, tweaked, improved, benchmarked, and so on. I intend to honor
    this deadline --- I cleared up my schedule starting from 1/15/2011, to
    spend 2 weeks working on it more or less uninterrupted. If anybody wants
    to chip in (some of you already wrote to me asking), you are welcome!
    Next week I plan to publish a list of areas I need help with (conceptual
    areas, not boring coding). Stay tuned!
    I am very interested in helping here. I'll ping your off list.
    I was sure at DDD and I am 100% sure now that the most important part of
    the "new deal" will be loaders, packages, and "web stores" / package
    repositories. I am pleased to see that we have something now, but I
    don't think it is mature enough. Even the package format is not fixed yet.
    I don't know about the package format, but the module format and loaders
    (requirejs and bdload) are pretty solid.
    Related question: are we going to identify any packages as "Dojo"? Are
    we going to have "Dojo Approved" program? Are we going to protect Dojo
    identity, and if yes --- how? What is our future Google/AOL CDN story?
    (The same goes for any other JavaScript library.)
    We *must* protect and grow the identity dojo; otherwise, this project just
    becomes a hobby rather than part of our livelihood.

    We can still release to CDN. I see nothing in the new module/package system
    that prevents this method of distribution. Do you?

    Best,
    Rawld
  • Rawld Gill at Jan 12, 2011 at 1:00 am
    I'll hang my reply off of the one Eugene chose...since he's a trend-setter!

    This is an awesome post Kris. I know we're all busy and tend to retreat into
    our own private purgatories of work, but this is the kind of conversion that
    we must continue (and have more often) if we and dojo are to be successful.

    I agree 100% with the overall message of this post.

    Re do it now:
    I agree. As far as base is concerned, we could upgrade/rewrite the base
    modules and add a small back-compat layer to make the new modules compatible
    with 1.x. I have prototyped this approach with dojo-sie. Clearly, it has its
    drawbacks. But, if we decide 2.0 is a "greenfield" project, then people will
    tend to work on that and forget 1.x. Eugene has advocated strongly (and
    I strongly agree) that we *cannot* have another 0.4 -> 0.9 fiasco. Greenfield
    is easier for us; evolving 1.x might be a better business decision.

    My opinion today is that we should not greenfield 2.0, but rather evolve 1.x;
    my reasons are:
    * we can start work on the day after 1.6 is released
    * v1.x will not be neglected, but rather will be improved

    But this is a close call, and I've changed my mind about this a couple of
    times already.

    What do others think? [Tom also touched on this issue in his reply]

    Re size matters:
    I strongly agree. This requires work on three fronts:
    * API design
    * API implementation
    * Build system

    Kris mentioned examples of API design and implementation; if the API and build
    system are designed appropriately, we can keep a feature-
    rich library while "building out" unused features for a particular app.

    In addition to the loader I've been working on, I'm nearing an alpha release
    of a complimentary build system (https://github.com/altoviso/bdBuild). This
    application takes a significant departure from the current build system in
    that it parses the javascript resources in order to make optimizations that
    are very difficult/error-prone/impossible with regex techniques (the parser,
    written in javascript, is at https://github.com/altoviso/bdParse). For
    example, the builder can eventually do things like remove functions never
    referenced (that's different than dead code).

    The point is this: every module/feature/function ought to be designed in such
    a way that it can be easily discarded during the build process.

    I could write another 2000 words; I'll spare you all.

    Best,
    Rawld


    On 1/10/11 9:40 AM, Kris Zyp wrote:
    I wanted to throw out some more thoughts on Dojo future and 2.0 and
    mobile.
  • Bill Keese at Jan 10, 2011 at 8:03 pm
    That's quite a manifesto :-). I'm glad your taking such an interest
    in 2.0. I want to reply to everything in your note but that might
    take weeks, so briefly:

    1) I agree that mobile should be the driver for 2.0. Like Alex said
    a few months ago, our window to be a player in the mobile toolkit
    space is rapidly closing. If we can just write a subset of dojo 2.0
    that works for mobile then we can fill in the gaps (IE support,
    desktop widgets, etc.) later.

    2) No one is really leading the dojo 2.0 effort as a whole. Perhaps
    you can be that guy.

    On Tue, Jan 11, 2011 at 12:40 AM, Kris Zyp wrote:
    I wanted to throw out some more thoughts on Dojo future and 2.0 and
    mobile. I have previously advocated delaying 2.0 as long as possible and trying
    to evolve the 1.x codebase as much as possible. However, as the need
    for a mobile presence is continuing to rise, and looking at what is
    needed for Dojo to be the greatest mobile framework on the planet, I
    think it is increasingly evident that 1.x base is too big and in many
    situations is non-optimal as an assumed include for creating lightweight mobile web
    applications. This is painfully demonstrated as we see that the Dojo
    committers themselves that are working on mobile additions are not
    willing to rely on Dojo base anymore. dojox.mobile.scrollable has
    self-bootstrapping system so it can run without dojo, dojox.mobile
    includes custom builds of dojo.js and Uxebu created
    EmbedJS to avoid the excessive size of Dojo base and it's modules.

    For the past year various Dojo committers have played around with
    various different projects and ideas that might fit into Dojo 2.0.
    These divergent paths have been very helpful, and there has been some
    fantastic progress in modularizing, optimizing, and shrinking
    Dojo-esque/Dojo-future modules. However, I think we need to start being able to
    utilize this stuff for the mobile side of things sooner rather than
    later, and perhaps we need to start looking at picking some of these
    paths and converging our efforts for Dojo 2.0. Even if Dojo 2.0 is not
    right around the corner, the need for the improved, more modularized
    components many of you have been working is immediate. I think it is
    important that Dojo mobile developers (like dojox.mobile and Wink) can
    start using components from EmbedJS, Uber.js, has.js, etc. The most
    critical thing we need now for this to work is basic interoperability.
    We really need AMD and CommonJS packaging for these projects. One of
    the reason I wanted to get the package system out there is so people
    could easily share these projects and start building things that
    utilize modules from different ones.

    Of course in the short term we aren't going to drop 1.x tomorrow. But again by looking at 2.0 it will help shape our progress with 1.x. I think on of the most important short term need is for
    these to be AMD compatible and packaged so mobile developers can start
    depending on, require()ing, using them (not just within EmbedJS,
    other's own system). AMD helps decouple us from particular
    implementations and allows us to more freely build components on
    a variety of different base modules. We can also be more explicit on modules from base that we rely on (like "dojo/connect" for example), rather than always assuming the presence of base. This makes it much more feasible to create alternate builds of Dojo base and progress towards more a modular future in 2.0.

    Here are some the projects that have been tossed around. I wanted to
    give my thoughts on some the strong points from each of these that I
    think deserve extra focus and attention as on track for Dojo 2.0 and our progress towards it. Perhaps there is or should be a wiki page to start flushing this stuff
    out more. Anyway, as far as some good stuff out there, IMO:

    http://github.com/phiggins42/has.js - Yes, we should be using this for
    feature detection. After AMD conversion, this is the next most
    important convention to follow so can have consistent feature
    detection that can be handled by builds (creating different builds
    based on device/feature sets). RequireJS 0.22 now supports build-level
    handling of has() branches. Which is awesome.

    http://github.com/phiggins42/uber.js - Peter and Bryan have done some
    great working demonstrating how modules can be written using has()
    feature detection in this project. The "array", "string", and
    "function" modules are some great modules for demonstrating that.
    Bryan and I have also been talking about some strategies with events
    and AOP to minimize code size. Eugene had a great suggestion, that we
    should separate AOP and events. I'd like to clarify how I believe this
    delineation should be made. This is not DOM vs plain objects, but AOP
    vs events, non-DOM objects should be able to be event
    emitters/listeners as well. Along these lines, I have suggested that
    an event listening function should have a super light branch for
    standards-based addEventListener, and if not available (IE <9) then
    depend on (maximize reuse) AOP code for DOM0 event handling (and don't
    waste bytes on having attachEvent code). Also, I would like to have
    consistency in our static AOP functions that operate on existing
    objects and the AOP decorators I have suggested for use in class
    creation (see next project down). before/after/around should mean the
    same thing whether it be on an existing object or a superclass.
    The uber.js modules would need to be upgraded to AMD format to use in
    Dojo 2. Bryan said he was planning on doing that.

    http://github.com/kriszyp/compose - The is an OO class that I proposed
    as a replacement for dojo.declare. The documentation should explain
    it, but it is intended to be much lighter and is influenced by traits,
    mixins, AOP, and decorators. This uses AOP decorators to achieve super
    calls.

    http://github.com/uxebu/embedjs - This is an awesome effort, lot's of
    cool stuff has been done here. However, any EmbedJS stuff that goes
    into Dojo 2.0 needs to get upgraded to AMD module format. Some of the
    individual parts of EmbedJS that I'd specifically like to see Dojo 2:
    ?* query - Awesome, I totally love what uxebu has done with query,
    this is the way to go.
    ?* async - I like how the main promise module is light, and they only
    load the back-compat API if necessary, good work.
    ?* uri - yeah, objectToQuery should be broken out of xhr.
    * array - Users can choose whether or not to apply array extras to
    Array.prototype (by loading native). Smart way to go.
    And lots of other modularization that is great.

    https://github.com/blowery/dojo-on - I am definitely a fan of spelling
    our event registration function "on()", it is succinct, matches
    NodeJS, and reads well. I am definitely not a fan of requiring the
    callback to provided in a separate then() call. Simple three argument
    (node, eventType, listener) calls for registering event handlers is
    the bread and butter of apps and shouldn't be complicated. We could
    return a promise compatible object from on() calls, but we still need
    to support providing the listener in the initial call. However, that
    being said, I would like to the event registration handled by compose
    (see below) to reuse the same code for AOP, super calls, event
    registration, and pubsub.

    http://bdframework.org/docs/loader/loader.html - Yes, pretty sure we
    want to use this. We have put a lot of effort in getting ready for
    this. Of course we also want to have RequireJS compatibility as well.
    Rawld has done an awesome job replicating the important features of
    RequireJS with a lightweight Dojo-ready version.

    http://github.com/uhop/pulsar - Eugene has jotted down a lot of good
    ideas in the comments on these modules. Both Eugene and Uxebu have hit
    on the need to break up html/dom. It is far too big as a single
    module. The project also nicely demonstrates our future package layout

    http://github.com/unscriptable/cujo - Looks like John is doing some
    great stuff with MVC. We really need to get better data binding
    support, I think.

    Rahul demonstrating a great data-binding system as well. It would be
    great to be able to move forward with this.

    Ben Hockey has been looking into higher level framework infrastructure as well.

    Other modules to think about:

    - json - We should feature detect and branch, using native JSON if
    available.

    - jsonp - This is actually completely unneeded now because it is a
    subset of AMD. We could a put module somewhere if we need to catch
    people's attention, but RequireJS and Backdraft should be able to
    JSONP OOTB by virtue of their module loading capability.


    - Separating general CSS look and feel from component specific CSS
    layout. We discussed this in another thread, and I still think we need
    a more extensible and easier to use theming system, and the ability to
    declare CSS as a dependency so users don't have to manually do it.
    Dustin and I have been talking about this, based on problems in
    earlier versions of Dojo when this was attempted to some degree. Some
    of the issues:
    * Script ordering is very important, loading a CSS that might load
    another CSS which unexpectedly takes precedence over something that
    was trying to override it must be avoided. We can't support transitive
    dependencies that would allow this to take place.
    * IE has a 31 stylesheet limit. I think this can be overcome by
    aggregating stylesheets when the limit is hit.
    * This should be done as an AMD plugin. John Hann has some code that
    does this already: http://github.com/unscriptable/cssx
    * There are two ways to load CSS, via XHR and inserting the response
    as CSS into a stylesheet, or creating a stylesheet with a src that
    points to the CSS to be loaded. Loading using src attribute is
    probably faster and easier. XHR could allow us to do processing on the
    CSS (supporting variables at runtime, doing proactive CSS3
    adjustments), but it is problematic for cross-domain and requires
    adjusting relative urls to match the CSS source's path. I'd prefer to
    use src to keep things as small as possible.
    * Ideally a theme is nothing more than generic CSS class definitions
    that are agnostic and decoupled from specific widget implementations,
    but there are times when individual components may need extra
    theme-specific CSS. We may want our CSS plugin to support
    theme-specific branching. The key here is that new components should
    be able to have theme specific CSS without adding CSS to the theme
    directory, and one should be able to create a new theme without adding
    to the individual component directories.
    * Even if we decide that this may be overly painful to retrofit
    existing widgets, we can and should be considering applying this
    concepts with new widgets, particularly in the mobile space, where
    selective loading could really help us to minimize downloaded bytes.

    Another cool idea that I see people doing is providing backwards
    compatiblity shims for CSS3 usage. I think that is being done in
    dojox.mobile and John has worked on that here as well:
    http://github.com/unscriptable/cssx

    - lang.js type checking (is.js in EmbedJS) - Please, this atrocity can
    not see the light of day in Dojo 2.0. Using dojo.isString(value)
    instead typeof value == "string", is slower, increases the size of our
    library, and allows primitive wrappers to permeate code (timebombs
    that we should be trying to eliminate).

    Other related notes include our new object store API (although that is already in 1.6), and moving GFX/Charting directly into Dojo core.

    Also, here are some more thoughts on dojox.mobile itself.

    - HTML5 elements (particularly form elements) - We really need to have
    a parser that can scan HTML for new HTML5 elements and back-shim with
    our widgets when the current browser doesn't natively support them.
    For the most part, this actually should not be very difficult to do,
    it is basically a matter of looking for <input>'s, finding the ones
    with a "type" that the browser doesn't support, and instantiating them
    with any necessary mappings to make sure our attributes match html5's.
    I think the most challenging part of this could be if we want to do
    build integration that can branch for different platforms to include
    or not include the widgets that are necessary to back-shim (since the
    main point is to reduce code size with native components). This type
    of parser could be created at anytime (doesn't need to wait for 2.0 or
    anything).

    - I'd love to see some consistency with list/grid handling such that
    the mobile list widgets and the desktop grids could inherit from a
    common hierarchy such that all would support arrays, inline <li> or
    <tr>'s, or stores for input.

    - Helpers to assist to with device normalization. I would think that a
    true multi-device web application might be structured like:
    * iphone - Load simple list, use HTML5 form, use iphone.css, light
    mobile widgets, no accessibility (hopefully 20-30K)
    * android - Load simple list, use HTML5 form, use android.css, light
    mobile widgets, no accessibility (hopefully 20-30K)
    * Desktop Firefox (or other modern HTML5 browser) - Use multiple
    column grid, use claro.css, desktop widgets with accessibility (hopefully 50-100K)
    * IE - Load claro.css, desktop widgets, HTML5 shim widgets
    (DateTextBox, ValidationTextBox, etc.), memory-leak protection, (and
    anything else we can download to give them a slower more painful
    experience ? ?:) ? . (100 - 150K)

    I think there a lot we could do to help with branching and loading different CSS, and making easy to create builds for different platforms and run-time branching to them.

    Anyway, hopefully these thoughts could help organize our efforts and focus our various projects to coalesce towards mobile-ready Dojo awesomeness.

    --
    Thanks,
    Kris




    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • James Burke at Jan 12, 2011 at 1:26 am

    On Mon, Jan 10, 2011 at 7:40 AM, Kris Zyp wrote:
    http://bdframework.org/docs/loader/loader.html - Yes, pretty sure we
    want to use this. We have put a lot of effort in getting ready for
    this. Of course we also want to have RequireJS compatibility as well.
    Rawld has done an awesome job replicating the important features of
    RequireJS with a lightweight Dojo-ready version.
    For what it is worth, I think this is a fine path to take for Dojo if
    the bd loader fits Dojo's needs better. It will help to have two
    strong AMD loaders that can be swapped in and out with each other.
    With the packaging of all the components, it should be easy to swap in
    either package for either loader, but for a "Dojo distribution" I can
    see specifying a particular one.

    I also wonder if a "Dojo distribution" just becomes a series of
    package manager calls, in some sort of macro/batch fetch script.
    - jsonp - This is actually completely unneeded now because it is a
    subset of AMD. We could a put module somewhere if we need to catch
    people's attention, but RequireJS and Backdraft should be able to
    JSONP OOTB by virtue of their module loading capability.
    Basic JSONP support works with AMD, but I wonder if a richer
    capability may be desired by some folks -- fancier error handling,
    proper script tag cleanup for long polling calls. But this is a minor
    point to the main message.

    To Rawld's point of trying to stay with 1.x, I do not believe that is
    as important in this new model, where there are discrete packages for
    components. I believe it will be different enough that there will be
    an upgrade discontinuity no matter what. With how Node operates with a
    package manager and smaller, more focused projects on GitHub, I
    believe that is how the future will go. It is best if the smaller
    focused project does not have to carry legacy baggage. It would be
    good to consider 1.x APIs, but not bend over backwards to support
    them.

    I would rather see a quicker coming together of these smaller focused
    projects than to try to figure out how to make them intelligible/easy
    to migrate for 1.x users. As others have mentioned in other contexts,
    I think the window is closing fast, and unless Dojo wants to just be
    into maintaining a 1.x tree, change will be good.

    I say all that, but I have not put in much code for Dojo lately, so
    weight the feedback accordingly. I've been working on broader AMD
    adoption and I will likely stay in that headspace for a while.

    James
  • Rawld Gill at Jan 12, 2011 at 1:15 pm
    On Tuesday 11 January 2011 22:26:09 James Burke wrote:
    [snip]
    To Rawld's point of trying to stay with 1.x, I do not believe that is
    as important in this new model, where there are discrete packages for
    components. I believe it will be different enough that there will be
    an upgrade discontinuity no matter what. With how Node operates with a
    package manager and smaller, more focused projects on GitHub, I
    believe that is how the future will go. It is best if the smaller
    focused project does not have to carry legacy baggage. It would be
    good to consider 1.x APIs, but not bend over backwards to support
    them.
    I am hesitant to argue my position too strongly because I believe there are
    significant drawbacks to either track. So...consider this a "devil's advocate"
    argument rather than "I absolutely believe this".

    I also think we should move to a new package model. I'm merely suggesting that
    we do it by migrating the 1.x tree and keeping a strong--though maybe not
    100%--backcompat module.

    We (I) could write a little module to implement 1.x require/provide so that
    current user code would work with dojo itself being a package loaded by an AMD
    loader.
    I would rather see a quicker coming together of these smaller focused
    projects than to try to figure out how to make them intelligible/easy
    to migrate for 1.x users. As others have mentioned in other contexts,
    I think the window is closing fast, and unless Dojo wants to just be
    into maintaining a 1.x tree, change will be good.
    It's my understanding that the projects we're talking about are mostly dojo
    base, with a little spill into dojo, and a tiny spill into dijit. Is that
    right? If so, we're talking about how to structure one package--dojo.

    Also, if dojo disrespects users of the 1.x tree, then I think there is a good
    possibility dojo will suffer terribly. So, we've got to be pretty careful
    here.

    Best,
    Rawld
  • Kris Zyp at Jan 12, 2011 at 9:27 pm
    Would it be premature to create a "v2" or "pulsar" branch of
    https://github.com/dojo/dojo that we could work on? As we get into
    actual code/modules/layout, it is so much easier to collaborate in the
    context of commits, in-line comments, and pull requests than trying to
    do it with email threads. Could we try to start merging code from
    uber.js, embedjs, has.js, etc. using git forks (and have something to
    start building back-compat modules with)?

    Also, I would love to see dojox.mobile migrated to a dojo mobile github
    project (maybe http://github.com/dojo/mobile?). We have been working
    hard to pave the way for this type of package, and it would be great to
    move forward with this key package.
    Thanks,
    Kris
  • Eugene Lazutkin at Jan 12, 2011 at 9:42 pm
    I think it is a little bit premature. Just wait until the end of
    January. But it doesn't mean that you should sit around twiddling your
    thumbs:

    Ultimately I want to have several versions of key modules so we can make
    an informed decision on what goes in, and what the alternatives are,
    with related trade offs. Specifically I want to see multiple versions of
    following things: event handling, promises, AOP, OOP, and functional
    helpers. To me these are key components of the kernel, we cannot be too
    careful in benchmarking/discussing them, we cannot have too much
    alternatives --- all ideas count. At the end I want to merge the best
    implementation ideas and interfaces into ~2 modules with different
    trade-offs: one should be the mainline, and another one is a specialty
    implementation trading one things for others, e.g., speed for size, or
    size for features.

    I will publish an extended email on all this next week --- this week I
    am super busy with current projects.

    Cheers,

    Eugene Lazutkin
    http://lazutkin.com/
    On 01/12/2011 08:27 PM, Kris Zyp wrote:
    Would it be premature to create a "v2" or "pulsar" branch of
    https://github.com/dojo/dojo that we could work on? As we get into
    actual code/modules/layout, it is so much easier to collaborate in the
    context of commits, in-line comments, and pull requests than trying to
    do it with email threads. Could we try to start merging code from
    uber.js, embedjs, has.js, etc. using git forks (and have something to
    start building back-compat modules with)?

    Also, I would love to see dojox.mobile migrated to a dojo mobile github
    project (maybe http://github.com/dojo/mobile?). We have been working
    hard to pave the way for this type of package, and it would be great to
    move forward with this key package.
    Thanks,
    Kris
  • Kris Zyp at Jan 12, 2011 at 10:59 pm

    On 1/12/2011 7:42 PM, Eugene Lazutkin wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    I think it is a little bit premature. Just wait until the end of
    January. But it doesn't mean that you should sit around twiddling your
    thumbs:
    Just out of curiosity, why is it premature? For the comparison of
    multiple versions of the components you described, Git seems the perfect
    tool. We could compare different pull requests, compare forks, compare
    different derivations on each module, comment inline on individuals
    commits, and line numbers, all in context. I would far rather have
    discussions on code in Git than on an archaic mailing list. Don't worry,
    we won't release 2.0 without you (of course the otherhand, I suppose I
    can wait three weeks) :).
    Ultimately I want to have several versions of key modules so we can make
    an informed decision on what goes in, and what the alternatives are,
    with related trade offs. Specifically I want to see multiple versions of
    following things: event handling, promises, AOP, OOP, and functional
    helpers. To me these are key components of the kernel, we cannot be too
    careful in benchmarking/discussing them, we cannot have too much
    alternatives --- all ideas count. At the end I want to merge the best
    implementation ideas and interfaces into ~2 modules with different
    trade-offs: one should be the mainline, and another one is a specialty
    implementation trading one things for others, e.g., speed for size, or
    size for features.
    Ok, some of my rough versions of some of these (mostly pretty focused on
    minimizing size):
    promises:
    https://github.com/kriszyp/promised-io/blob/master/lib/promise.js#L144-272
    <https://github.com/kriszyp/promised-io/blob/master/lib/promise.js#L144>
    (minus the context stuff)
    AOP: https://github.com/kriszyp/uber.js/blob/master/src/aop.js
    event handling (just the core handling, doesn't deal with browser
    normalization of event actions, but I believe that should be in a
    separate module):
    https://github.com/kriszyp/uber.js/blob/master/src/events.js
    <https://github.com/kriszyp/uber.js/blob/master/src/aop.js>
    OOP: https://github.com/kriszyp/compose
    functional helpers: Nothing to offer here, I generally don't like to use
    these.

    Thanks,
    Kris
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110112/051badf6/attachment.htm
  • Eugene Lazutkin at Jan 12, 2011 at 11:11 pm
    Inline.
    On 01/12/2011 09:59 PM, Kris Zyp wrote:
    On 1/12/2011 7:42 PM, Eugene Lazutkin wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    I think it is a little bit premature. Just wait until the end of
    January. But it doesn't mean that you should sit around twiddling your
    thumbs:
    Just out of curiosity, why is it premature? For the comparison of
    multiple versions of the components you described, Git seems the perfect
    tool. We could compare different pull requests, compare forks, compare
    different derivations on each module, comment inline on individuals
    commits, and line numbers, all in context. I would far rather have
    discussions on code in Git than on an archaic mailing list. Don't worry,
    we won't release 2.0 without you (of course the otherhand, I suppose I
    can wait three weeks) :).
    You asked --- I answered. As far as I know I cannot prohibit you or
    anybody else from cloning projects on github. ;-) I just suggest that
    the code in question:

    a) doesn't work
    b) will change a lot

    It would be more productive to work with something better than the
    current state of Pulsar. But go ahead and clone to your liking.

    BTW, be my guest and release Dojo 2.0 --- last time I checked "Dojo" is
    not copyrighted and anybody can release Dojo This, Dojo That, and even
    Dojo 3.5. Of course I expect it to be much better than Dojo 1.x and not
    released just to be released, but to solve actual developer's problems
    we have with the current codebase.
    Ok, some of my rough versions of some of these (mostly pretty focused on
    minimizing size):
    promises:
    https://github.com/kriszyp/promised-io/blob/master/lib/promise.js#L144-272
    <https://github.com/kriszyp/promised-io/blob/master/lib/promise.js#L144>
    (minus the context stuff)
    AOP: https://github.com/kriszyp/uber.js/blob/master/src/aop.js
    event handling (just the core handling, doesn't deal with browser
    normalization of event actions, but I believe that should be in a
    separate module):
    https://github.com/kriszyp/uber.js/blob/master/src/events.js
    <https://github.com/kriszyp/uber.js/blob/master/src/aop.js>
    OOP: https://github.com/kriszyp/compose
    functional helpers: Nothing to offer here, I generally don't like to use
    these.
    See, you don't need to clone anything to offer alternatives. :-) I saw
    practically all of them.

    Cheers,

    Eugene
    Thanks,
    Kris



    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Bill Keese at Jan 12, 2011 at 10:54 pm
    +1 to move forward on a 2.0 github repository, waiting until end of January
    as per Eugene's request.

    I'd also love to see dojox.mobile run on dojo V2, but note that it depends
    on dijit a little, for dijit._Widget and dijit._base at least, plus it sort
    of depends on _FormWidget and TextBox in the sense that it has copy/pasted
    versions of those files, a practice that we can hopefully discontinue for
    2.0, especially if the build tool can remove unneeded code branches (ex:
    keyboard support isn't needed on iPhone). So we'd need to get the V2
    version of those files too (regardless of what package name they live in)
    On Thu, Jan 13, 2011 at 11:27 AM, Kris Zyp wrote:

    Would it be premature to create a "v2" or "pulsar" branch of
    https://github.com/dojo/dojo that we could work on? As we get into
    actual code/modules/layout, it is so much easier to collaborate in the
    context of commits, in-line comments, and pull requests than trying to
    do it with email threads. Could we try to start merging code from
    uber.js, embedjs, has.js, etc. using git forks (and have something to
    start building back-compat modules with)?

    Also, I would love to see dojox.mobile migrated to a dojo mobile github
    project (maybe http://github.com/dojo/mobile?). We have been working
    hard to pave the way for this type of package, and it would be great to
    move forward with this key package.
    Thanks,
    Kris

    _______________________________________________
    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/20110113/3a8232e5/attachment-0001.htm
  • Bill Keese at Jan 13, 2011 at 3:12 am
    Some replies to Kris' many bullet points (see inline):
    On Tue, Jan 11, 2011 at 12:40 AM, Kris Zyp wrote:

    We can also be more explicit on modules from base that we rely on (like
    "dojo/connect" for example), rather than always assuming the presence of
    base. This makes it much more feasible to create alternate builds of Dojo
    base and progress towards more a modular future in 2.0.
    Makes sense. Base is just a marketing tool, it doesn't have any technical
    meaning what is/isn't in base. And on a more practical note, lightweight
    apps don't want stuff like dojo.query().


    Eugene had a great suggestion, that we
    should separate AOP and events. I'd like to clarify how I believe this
    delineation should be made. This is not DOM vs plain objects, but AOP
    vs events, non-DOM objects should be able to be event
    emitters/listeners as well. Along these lines, I have suggested that
    an event listening function should have a super light branch for
    standards-based addEventListener, and if not available (IE <9) then
    depend on (maximize reuse) AOP code for DOM0 event handling (and don't
    waste bytes on having attachEvent code).

    You lost me. Don't you need attachEvent to support IE6, 7, and 8?


    Also, I would like to have
    consistency in our static AOP functions that operate on existing
    objects and the AOP decorators I have suggested for use in class
    creation (see next project down). before/after/around should mean the
    same thing whether it be on an existing object or a superclass.
    OK. I can only think of one possible meaning for before/after/around
    anyway, not sure what possible inconsistency you were referring to.


    http://github.com/kriszyp/compose - The is an OO class that I proposed
    as a replacement for dojo.declare. The documentation should explain
    it, but it is intended to be much lighter and is influenced by traits,
    mixins, AOP, and decorators. This uses AOP decorators to achieve super
    calls.
    Not sure we finished the discussion on this. The last email in the original
    thread (http://thread.gmane.org/gmane.comp.web.dojo.devel/13527/focus557)
    talked about "shaman's ritual" and I have no idea what that means. But I
    like ComposeJS if only because it resolves inheritance at declaration time
    rather than at runtime, making stepping through code in the debugger
    easier.

    Probably we'd need to standardize on ComposJS as I doubt that it
    mixes/matches well with dojo.declare().


    http://github.com/uxebu/embedjs - This is an awesome effort, lot's of
    cool stuff has been done here. However, any EmbedJS stuff that goes
    into Dojo 2.0 needs to get upgraded to AMD module format. Some of the
    individual parts of EmbedJS that I'd specifically like to see Dojo 2:
    * query - Awesome, I totally love what uxebu has done with query,
    this is the way to go.
    You mean how they have a lightweight version that just handles simple
    queries? Seems good, although I would hope that we wouldn't need a query
    module at all on most browsers (especially most mobile browsers), and could
    just use a thin wrapper around querySelectorAll().


    https://github.com/blowery/dojo-on - I am definitely a fan of spelling
    our event registration function "on()", it is succinct, matches
    NodeJS, and reads well. I am definitely not a fan of requiring the
    callback to provided in a separate then() call. Simple three argument
    (node, eventType, listener) calls for registering event handlers is
    the bread and butter of apps and shouldn't be complicated. We could
    return a promise compatible object from on() calls, but we still need
    to support providing the listener in the initial call. However, that
    being said, I would like to the event registration handled by compose
    (see below) to reuse the same code for AOP, super calls, event
    registration, and pubsub.
    What's wrong with having the callback in a then() call? You're implying
    that it's more complicated, but

    dojo.on("someNode", "click", handler)


    vs.

    dojo.on("someNode", "click").then(handler)


    They seem more or less the same to me.

    The other thing I don't understand is, how is

    dojo.on("someNode", "click", handler)

    different than the old format?:

    dojo.connect("someNode", "click", handler)


    - Separating general CSS look and feel from component specific CSS
    layout. We discussed this in another thread, and I still think we need
    a more extensible and easier to use theming system, and the ability to
    declare CSS as a dependency so users don't have to manually do it.
    It would be good to try, although as you mentioned we did that in 0.4 and
    got rid of it. Dylan was the one who kept talking about how it was too
    much magic. Some things to consider:

    - there would need to be a theme setting for the page, or perhaps per
    widget
    - custom themes

    Another cool idea that I see people doing is providing backwards
    compatiblity shims for CSS3 usage. I think that is being done in
    dojox.mobile and John has worked on that here as well:
    http://github.com/unscriptable/cssx

    That is cool, but I remember looking at one implementation and it seemed
    pretty limited in that it didn't work dynamically, i.e. it wouldn't work for
    DOMNodes created after the script was run. Not sure about this package.

    - HTML5 elements (particularly form elements) - We really need to have
    a parser that can scan HTML for new HTML5 elements and back-shim with
    our widgets when the current browser doesn't natively support them.
    For the most part, this actually should not be very difficult to do,
    it is basically a matter of looking for <input>'s, finding the ones
    with a "type" that the browser doesn't support, and instantiating them
    with any necessary mappings to make sure our attributes match html5's.
    I think the most challenging part of this could be if we want to do
    build integration that can branch for different platforms to include
    or not include the widgets that are necessary to back-shim (since the
    main point is to reduce code size with native components). This type
    of parser could be created at anytime (doesn't need to wait for 2.0 or
    anything).
    Yes, I've thought of this too, it would be a fun addition. There are lots
    of ways to code it, including a simple dojo.query() script to run before the
    parser runs.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110113/2e724ea0/attachment-0001.htm
  • Bryan Forbes at Jan 13, 2011 at 3:26 am

    On 1/13/11 2:12 AM, Bill Keese wrote:
    Eugene had a great suggestion, that we
    should separate AOP and events. I'd like to clarify how I believe this
    delineation should be made. This is not DOM vs plain objects, but AOP
    vs events, non-DOM objects should be able to be event
    emitters/listeners as well. Along these lines, I have suggested that
    an event listening function should have a super light branch for
    standards-based addEventListener, and if not available (IE <9) then
    depend on (maximize reuse) AOP code for DOM0 event handling (and don't
    waste bytes on having attachEvent code).


    You lost me. Don't you need attachEvent to support IE6, 7, and 8?
    No. In fact, dojo.connect doesn't actually use attachEvent, but uses
    DOM0 (elem.onevent = createDispatcher()) for IE.

    - --
    Bryan Forbes
    http://www.reigndropsfall.net

    GPG Fingerprint
    3D7D B728 713A BB7B B8B1 5B61 3888 17E0 70CA 0F3D
  • Bryan Forbes at Jan 13, 2011 at 3:29 am

    On 1/13/11 2:26 AM, Bryan Forbes wrote:
    On 1/13/11 2:12 AM, Bill Keese wrote:
    Eugene had a great suggestion, that we
    should separate AOP and events. I'd like to clarify how I believe this
    delineation should be made. This is not DOM vs plain objects, but AOP
    vs events, non-DOM objects should be able to be event
    emitters/listeners as well. Along these lines, I have suggested that
    an event listening function should have a super light branch for
    standards-based addEventListener, and if not available (IE <9) then
    depend on (maximize reuse) AOP code for DOM0 event handling (and don't
    waste bytes on having attachEvent code).
    You lost me. Don't you need attachEvent to support IE6, 7, and 8?
    No. In fact, dojo.connect doesn't actually use attachEvent, but uses
    DOM0 (elem.onevent = createDispatcher()) for IE.
    I forgot to mention that the reason we doesn't use attachEvent is
    because handlers registered with attachEvent fire in random order:

    http://msdn.microsoft.com/en-us/library/ms536343(v=vs.85).aspx

    - --
    Bryan Forbes
    http://www.reigndropsfall.net

    GPG Fingerprint
    3D7D B728 713A BB7B B8B1 5B61 3888 17E0 70CA 0F3D
  • Bill Keese at Jan 13, 2011 at 4:11 am
    Ah right, in that case sounds like a good idea. It goes along with the
    general principle (first proposed by James IIRC) to write the main dojo code
    as though legacy browsers didn't exist, and then have plugins (or whatever
    you want to call them) for supporting old browsers, specifically IE.
    On Thu, Jan 13, 2011 at 5:29 PM, Bryan Forbes wrote:

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1
    On 1/13/11 2:26 AM, Bryan Forbes wrote:
    On 1/13/11 2:12 AM, Bill Keese wrote:
    Eugene had a great suggestion, that we
    should separate AOP and events. I'd like to clarify how I believe
    this
    delineation should be made. This is not DOM vs plain objects, but
    AOP
    vs events, non-DOM objects should be able to be event
    emitters/listeners as well. Along these lines, I have suggested that
    an event listening function should have a super light branch for
    standards-based addEventListener, and if not available (IE <9) then
    depend on (maximize reuse) AOP code for DOM0 event handling (and
    don't
    waste bytes on having attachEvent code).
    You lost me. Don't you need attachEvent to support IE6, 7, and 8?
    No. In fact, dojo.connect doesn't actually use attachEvent, but uses
    DOM0 (elem.onevent = createDispatcher()) for IE.
    I forgot to mention that the reason we doesn't use attachEvent is
    because handlers registered with attachEvent fire in random order:

    http://msdn.microsoft.com/en-us/library/ms536343(v=vs.85).aspx

    - --
    Bryan Forbes
    http://www.reigndropsfall.net

    GPG Fingerprint
    3D7D B728 713A BB7B B8B1 5B61 3888 17E0 70CA 0F3D
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.11 (Darwin)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

    iEYEARECAAYFAk0uuAYACgkQOIgX4HDKDz3MxQCfcQthfMZ+HtNoDGU987T7sKnv
    7psAoJcQa0MYRLqZTvDdbEOvS+A4B3cQ
    =b2Os
    -----END PGP SIGNATURE-----
    _______________________________________________
    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/20110113/5f76da03/attachment.htm
  • James Thomas at Jan 13, 2011 at 6:03 am

    On 10 January 2011 15:40, Kris Zyp wrote:
    http://github.com/phiggins42/has.js - Yes, we should be using this for
    feature detection. After AMD conversion, this is the next most
    important convention to follow so can have consistent feature
    detection that can be handled by builds (creating different builds
    based on device/feature sets). RequireJS 0.22 now supports build-level
    handling of has() branches. Which is awesome.
    +1

    RequireJS supports build-level handling of the "has()" branches using
    Google Closure compiler to perform dead-code branch removal. Unless
    I've missed something, I didn't think the standard build process using
    Shrinksafe supports this? Are we planning to put this new
    functionality into the existing build tools or are we looking at
    completely replacing the build system with Rawld's proposal?
    http://bdframework.org/docs/loader/loader.html - Yes, pretty sure we
    want to use this. We have put a lot of effort in getting ready for
    this. Of course we also want to have RequireJS compatibility as well.
    Rawld has done an awesome job replicating the important features of
    RequireJS with a lightweight Dojo-ready version.
    This looks great. Is there somewhere that gives a better explanation
    of the differences
    between this loader and RequireJS? I've had a look at
    http://bdframework.org/docs/loader/loader.html
    but didn't see any specific comparison information.
    http://github.com/unscriptable/cujo - Looks like John is doing some
    great stuff with MVC. We really need to get better data binding
    support, I think.

    Rahul demonstrating a great data-binding system as well. It would be
    great to be able to move forward with this.

    Ben Hockey has been looking into higher level framework infrastructure as well.
    +1

    Good data-binding support would be a great addition to the toolkit and
    ties in with other parts of the toolkit, dojo.store/dojo.stateful.
    We already have some modules that try to do this, e.g. dojox.wires,
    and there are lots of really good new proposals like
    http://github.com/unscriptable/cujo and
    http://doughays.dojotoolkit.org/dojomvc/.

    I guess our final approach will be a combination of all of these.

    Is the higher level app. framework something we want Dojo to help
    with? There seems to be more of these projects sprouting up, e.g.
    backbone (http://documentcloud.github.com/backbone/), JavascriptMVC
    (http://www.javascriptmvc.com/), etc.

    Having a quick review, common features these frameworks provide and we
    currently don't include:
    - Page Controllers/View Routing
    - App Layout setup
    - HTML5 elements (particularly form elements) - We really need to have
    a parser that can scan HTML for new HTML5 elements and back-shim with
    our widgets when the current browser doesn't natively support them.
    For the most part, this actually should not be very difficult to do,
    it is basically a matter of looking for <input>'s, finding the ones
    with a "type" that the browser doesn't support, and instantiating them
    with any necessary mappings to make sure our attributes match html5's.
    I think the most challenging part of this could be if we want to do
    build integration that can branch for different platforms to include
    or not include the widgets that are necessary to back-shim (since the
    main point is to reduce code size with native components). This type
    of parser could be created at anytime (doesn't need to wait for 2.0 or
    anything).
    Would this always be a completely separate parser or eventually
    integrated into the normal parser? Also, isn't this relevant to all
    browser platforms not just mobile? It's a nice idea!

    Other thoughts.....

    - Templating. There was a discussion at DDD around the choice of
    templating system in the future. Are we planning to change the
    templating system in Dojo 2.0?

    - HTML5 Element Support. Is there a proposal of whether and how we
    support native HTML5 elements within Dijit widgets whose functionality
    overlaps, e.g. date picker?

    - CSS frameworks. People have been playing with LESS and SASS, did
    someone make a decision about using one of these in the future?

    - DojoX Modules. Is the DojoX part of the project going to be orphaned
    off as we move towards Dojo 2?

    Sorry for asking lots of questions and providing very few answers!

    Regards,
    James Thomas
  • Bill Keese at Jan 13, 2011 at 7:36 am

    Answers to some of the dijit questions:



    - Templating. There was a discussion at DDD around the choice of
    templating system in the future. Are we planning to change the
    templating system in Dojo 2.0?
    I think that mustache [and similar engines] are too big to be dijit's
    default template engine, but Dustin's argument is to have a build step to
    precompile all the templates into JS code. For example, the current
    TextBox.js wouldn't change, but the *built* TextBox.js would be something
    like:

    dojo.declare("dijit.form.TextBox", ... {
    buildRendering: function(){
    this.domNode = dojo.toDom("<input name=" + name + ">");
    }
    }

    Then we could make mustache or whatever the default template engine.

    Until then we can keep supporting mustache as an alternate to dijit's
    default template engine.


    - HTML5 Element Support. Is there a proposal of whether and how we
    support native HTML5 elements within Dijit widgets whose functionality
    overlaps, e.g. date picker?
    By "support" I assume you mean "take advantage of"?

    It would be tough to use the native date picker in general, even on browsers
    where it's available, because:

    1) the look and feel won't match other claro widgets
    2) it's missing advanced features like disabling certain dates

    etc.

    I'm sure some apps would make that trade off to reduce their JS footprint,
    especially mobile apps, but it's not a feature that I think should be part
    of dijit itself.


    - CSS frameworks. People have been playing with LESS and SASS, did
    someone make a decision about using one of these in the future?
    I setup less for dijit, see the files in dijit/themes/claro. Still work
    to be done there.


    >
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110113/700fe37a/attachment.htm
  • Sasha Firsov at Jan 13, 2011 at 12:04 pm
    Templating.

    It has been quite strong will from multiple teams to use HTML templates
    instead of embedded JS strings.
    The reasons where different but all strong enough:
    - HTML could be validated against schema in early stage in editor.
    Rather collecting mysterious bugs on wrongly closed tags and other
    malformed HTML.
    - HTML with multiple templates combined loaded way faster than templates
    as JS string.
    - per-widget template which assembles during compilation into common
    resource HTML. This common HTML is a separate test layer, this time for
    pure HTML validation. Target of compilation in addition to release the
    load test and time profile(multiple instances shuffled on HTML)
    - template DOM subtree could be part of current page.
    * Given option for template preview during development without
    actual widget created.
    * DOM node clone is more efficient than innerHTML set(?)

    Yes, customization of dijit for the features above was required and had
    been in place. Additional parameter to template load parameter was used.
    In our case it was an ID in template to support multiple templates in
    single HTML.
    Primary format XHTML in strict mode. Selectors as ID are not sufficient.
    For example anchor name: "templates.xhtml#MyDijitID". I prefer XPath,
    some CSS3 selectors. I guess we should not limit user on their choice.
    Still, sticking to primary method on our own.

    For simple cases all of above is overkill, so old-facioned JS ones are
    also need to be in place. But in approved widgets would be nice to keep
    all in most verifiable format as subject for HTML (not JS) load testing
    and profiling.
    Since template need to be modified before using, it could be done in
    various ways.
    One side of merging is the template, but another is browser model (JS
    scope,DOM,etc).
    selector-in-JS meant to get value by formalized string. dijit object
    variable for example. Or language-dependent string from XML vocabulary.
    - for JS strings we used string substitution and RegEx
    - for (X)HTML template we could use selectors and provide support
    functions to apply map selector-in-JS to selector-in-template.
    - The XSL gives pretty good flexibility and performance on XML on both
    sides(data and template).
    - compiled data selector code could be an alternative. Data mining
    formal string during compilation could be changed into JS code or native
    selector(XPath for XML, CSS selector for HTML, regEx for string).

    It could sound quite sophisticated but in reality is not.
    Sasha
    On 1/13/2011 4:36 AM, Bill Keese wrote:
    Answers to some of the dijit questions:

    - Templating. There was a discussion at DDD around the choice of
    templating system in the future. Are we planning to change the
    templating system in Dojo 2.0?


    I think that mustache [and similar engines] are too big to be dijit's
    default template engine, but Dustin's argument is to have a build step
    to precompile all the templates into JS code. For example, the
    current TextBox.js wouldn't change, but the *built* TextBox.js would
    be something like:

    dojo.declare("dijit.form.TextBox", ... {
    buildRendering: function(){
    this.domNode = dojo.toDom("<input name=" + name + ">");
    }
    }

    Then we could make mustache or whatever the default template engine.

    Until then we can keep supporting mustache as an alternate to dijit's
    default template engine.



    - HTML5 Element Support. Is there a proposal of whether and how we
    support native HTML5 elements within Dijit widgets whose functionality
    overlaps, e.g. date picker?


    By "support" I assume you mean "take advantage of"?

    It would be tough to use the native date picker in general, even on
    browsers where it's available, because:

    1) the look and feel won't match other claro widgets
    2) it's missing advanced features like disabling certain dates

    etc.

    I'm sure some apps would make that trade off to reduce their JS
    footprint, especially mobile apps, but it's not a feature that I think
    should be part of dijit itself.



    - CSS frameworks. People have been playing with LESS and SASS, did
    someone make a decision about using one of these in the future?


    I setup less for dijit, see the files in dijit/themes/claro. Still
    work to be done there.




    _______________________________________________
    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/20110113/18792547/attachment.htm
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/pkcs7-signature
    Size: 5199 bytes
    Desc: S/MIME Cryptographic Signature
    Url : http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110113/18792547/attachment.p7s
  • Rawld Gill at Jan 13, 2011 at 12:23 pm

    On Thursday 13 January 2011 03:03:45 James Thomas wrote:
    On 10 January 2011 15:40, Kris Zyp wrote:
    http://github.com/phiggins42/has.js - Yes, we should be using this for
    feature detection. After AMD conversion, this is the next most
    important convention to follow so can have consistent feature
    detection that can be handled by builds (creating different builds
    based on device/feature sets). RequireJS 0.22 now supports build-level
    handling of has() branches. Which is awesome.
    +1

    RequireJS supports build-level handling of the "has()" branches using
    Google Closure compiler to perform dead-code branch removal. Unless
    I've missed something, I didn't think the standard build process using
    Shrinksafe supports this? Are we planning to put this new
    functionality into the existing build tools or are we looking at
    completely replacing the build system with Rawld's proposal?
    I'm still working on my builder so that the community can evaluate and decide
    if this is the way to go. Having said that, the current build *must* be
    replaced by something. It's too slow and too limited by its use of regexs.

    Re has and build:
    I think the has! plugin is the wrong design in the strongest sense. The short
    reason is that it is completely unnecessary, to wit:

    define([has("some-feature")?"some/module":"some/other/module"], //...

    does the same thing and doesn't need a plugin.

    We can discuss this under a separate thread when has! appears in the code.
    http://bdframework.org/docs/loader/loader.html - Yes, pretty sure we
    want to use this. We have put a lot of effort in getting ready for
    this. Of course we also want to have RequireJS compatibility as well.
    Rawld has done an awesome job replicating the important features of
    RequireJS with a lightweight Dojo-ready version.
    This looks great. Is there somewhere that gives a better explanation
    of the differences
    between this loader and RequireJS? I've had a look at
    http://bdframework.org/docs/loader/loader.html
    but didn't see any specific comparison information.
    I'll get something out along these lines. But, the short answer is that bdLoad
    can be configured (with has switches) to be 100% compatible with requirejs for
    all the core requirejs features.

    The key feature bdLoad and requirejs implement differently is contexts.
    However, both loaders can load two different packages of the same name or two
    different versions of the same package; they just have different ways of
    approaching the problem.

    The key differentiator for using bdLoad is size: the latest *built* version of
    bdLoad suitable for use with dojo came in at around 3.2K which is quite a bit
    smaller than requirejs. It also has options to build it smaller. I have been
    able to get a v1.6 dojo base with QSA, no dojo.declare, no dojo.array, and
    just enough loader features to load base very close to 20K in experiments (I
    think less, but I can't exactly remember where I ended the experiment).

    Both loaders perform about the same.

    Best,
    Rawld
  • Ben hockey at Jan 13, 2011 at 1:42 pm

    On 1/13/2011 12:23 PM, Rawld Gill wrote:
    Re has and build:
    I think the has! plugin is the wrong design in the strongest sense. The short
    reason is that it is completely unnecessary, to wit:

    define([has("some-feature")?"some/module":"some/other/module"], //...

    does the same thing and doesn't need a plugin.
    that's assuming that has("some-feature") can be evaluated correctly at
    build time. this is where the plugin comes in, the has plugin acts as a
    wrapper to has proper and can determine if it is being called during a
    build and respond appropriately based on a static config rather than the
    environment in which has is being currently called.
  • Rawld Gill at Jan 13, 2011 at 2:19 pm

    On Thursday 13 January 2011 10:42:59 ben hockey wrote:
    On 1/13/2011 12:23 PM, Rawld Gill wrote:
    Re has and build:
    I think the has! plugin is the wrong design in the strongest sense. The
    short reason is that it is completely unnecessary, to wit:

    define([has("some-feature")?"some/module":"some/other/module"], //...

    does the same thing and doesn't need a plugin.
    that's assuming that has("some-feature") can be evaluated correctly at
    build time. this is where the plugin comes in, the has plugin acts as a
    wrapper to has proper and can determine if it is being called during a
    build and respond appropriately based on a static config rather than the
    environment in which has is being currently called.
    No, the plugin is not required for the build.

    has! introduces an extra-lingual feature that happens to be detected by
    requirejs's optimizer [builder]. So, to insist on the has! plugin is also to
    insist on more requirements for the builder. Maybe it's just the has plugin,
    but its an additional requirement nevertheless.

    But, another design is to detect, e.g., 'has("some-
    feature")?"some/module":"some/other/module"' by the builder. That's what
    bdBuild does. And this kind of detection is *already available* if you allow
    build-time optimization of has.

    By not employing a has! plugin, there are two orthogonal technologies:
    * AMD loading
    * feature detection via the has API

    You don't need to understand some new API (e.g. has!) to use has with the
    loader.

    You don't use has one way with the loader and another way elsewhere in the
    code.

    You don't need to write a plugin.

    Each technology can evolve independent of the other.

    By being independent, they are each smaller and easier to design, build,
    document, maintain, and understand.

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • James Burke at Jan 13, 2011 at 2:25 pm

    On Thu, Jan 13, 2011 at 11:19 AM, Rawld Gill wrote:
    You don't need to write a plugin.

    Each technology can evolve independent of the other.

    By being independent, they are each smaller and easier to design, build,
    document, maintain, and understand.
    I think Ben may have a point, in that has would need to be a global
    that exists outside of a strictly scoped module. I'm not sure that is
    desirable in all module systems. It would work in RequireJS because
    you can still twiddle the global object with a module, but I can see
    it undesirable if you want all modules to not export a global. I
    certainly prefer it to not be a global.

    I can also appreciate wanting to keep the feature set understood by a
    loader to be to a very minimum though. So it is a tough choice.

    James
  • Rawld Gill at Jan 14, 2011 at 1:56 am

    On Thursday 13 January 2011 11:25:14 James Burke wrote:
    On Thu, Jan 13, 2011 at 11:19 AM, Rawld Gill wrote:
    You don't need to write a plugin.

    Each technology can evolve independent of the other.

    By being independent, they are each smaller and easier to design, build,
    document, maintain, and understand.
    I think Ben may have a point, in that has would need to be a global
    that exists outside of a strictly scoped module.
    Great point James; sorry I missed that Ben.

    I think the loader and has have "special" status because they bootstrap
    everything else.

    bdLoad includes the feature to specify a has implementation
    to its constructor so that the loader itself can use has.js. Part of this
    feature is to instruct the loader to go ahead and create a has module based on
    the implementation provided to the loader constructor. The net effect is that
    after the loader is defined, a has module exists and is fully functional so
    you can write...

    define(["has"], function(has) {
    //...
    });

    or

    define([require("has")["feature"]?"some/module":"some/other/module"], //...

    I concede:

    * this adds complexity to the loader (although the complexity cost is 3 lines
    and the loader and has implementation are still independent).

    * the syntax of the second example above is ugly (although feature-dependent
    dependencies are rare).

    Also, Kris did an excellent job of putting has.js into a package
    (https://github.com/kriszyp/has.js). So, there is another way to get has into
    a module. This doesn't completely fix the has requirement in the deps list,
    and I don't have an immediate, elegant solution to this problem without
    relying on the loader automatically loading has as described above.
    I'm not sure that is
    desirable in all module systems. It would work in RequireJS because
    you can still twiddle the global object with a module, but I can see
    it undesirable if you want all modules to not export a global. I
    certainly prefer it to not be a global.

    I can also appreciate wanting to keep the feature set understood by a
    loader to be to a very minimum though. So it is a tough choice.
    Seems like we need to add this to the list of things Eugene wants to
    critically benchmark and debate, which is appropriate for such a foundational
    issue.

    Best,
    Rawld
  • Kris Zyp at Jan 14, 2011 at 1:45 am

    On 1/13/2011 10:23 AM, Rawld Gill wrote:
    On Thursday 13 January 2011 03:03:45 James Thomas wrote:
    On 10 January 2011 15:40, Kris Zyp wrote:
    http://github.com/phiggins42/has.js - Yes, we should be using this for
    feature detection. After AMD conversion, this is the next most
    important convention to follow so can have consistent feature
    detection that can be handled by builds (creating different builds
    based on device/feature sets). RequireJS 0.22 now supports build-level
    handling of has() branches. Which is awesome.
    +1

    RequireJS supports build-level handling of the "has()" branches using
    Google Closure compiler to perform dead-code branch removal. Unless
    I've missed something, I didn't think the standard build process using
    Shrinksafe supports this? Are we planning to put this new
    functionality into the existing build tools or are we looking at
    completely replacing the build system with Rawld's proposal?
    I'm still working on my builder so that the community can evaluate and decide
    if this is the way to go. Having said that, the current build *must* be
    replaced by something. It's too slow and too limited by its use of regexs.

    Re has and build:
    I think the has! plugin is the wrong design in the strongest sense. The short
    reason is that it is completely unnecessary, to wit:

    define([has("some-feature")?"some/module":"some/other/module"], //...

    does the same thing and doesn't need a plugin.
    This approach does have the disadvantage that "has" can not be treated
    as an on-demand module, it has be loaded (presumably by a script tag, or
    actually embedded in the module loader (is James going to go for that in
    RequireJS?)) and made available as a global. Part of the whole idea of
    our module system is to avoid globals and manual dependencies. This also
    increases the number of constructs in the language that need to be
    analyzed (ternary and if/else). An alternate way of avoiding the "has"
    plugin would be:

    define({
    var has = require("has");
    if(has("some-feature")){
    var m = require("some/module");
    }else{
    var m = require("some/other/module");
    }
    });

    This style has the advantage that we are consistently using if/else
    blocks for has()-based branching, and has() can be loaded as a module
    (no manual dependency handling or globals).

    Anyway, there is enough pros and cons to each different approach
    (has-plugin, global has() ternary, and require("has") with if/else) that
    I don't really have a strong opinion which is best. I would hope we
    could decide on one though.
    Kris
  • James Burke at Jan 14, 2011 at 1:16 pm

    On Thu, Jan 13, 2011 at 10:45 PM, Kris Zyp wrote:
    Anyway, there is enough pros and cons to each different approach
    (has-plugin, global has() ternary, and require("has") with if/else) that
    I don't really have a strong opinion which is best. I would hope we
    could decide on one though.
    I'm going to answer on this thread since Kris was good about changing
    the subject line, but I have read Rawld's response on the other
    thread.

    I only plan to support a has! plugin. I do not want to create a global
    or special global for this feature. I believe there could be more than
    one type of has plugin (in fact I expect it, I would like to see a web
    tool so you only have to embed the has tests you need and generate a
    plugin module from that). Loading of that specialized has plugin the
    may be on a different path:

    define(['./has!test?true:false', 'global/has!test?true:fase'], function (){})

    By using this approach it does not make one has thing more special
    than the other.

    What is supported in the RequireJS build tool is has("test")
    replacement, and those should happen inside the module's factory
    function. I expect that people who want to opt into it will create a
    local variable (or factory function argument) for the has they want to
    participate in that build optimization:

    define(function(require){
    var has = require('has');
    if (has('test')) {
    //true
    } else {
    //false
    }
    });

    So even though there is special treatment of a has variable inside a
    factory function, that has variable is controlled by the developer,
    and it is a locally scoped value. It also only gets processed if the
    developer creates a has: object in the build profile.

    I prefer this form:

    define(['./has!test?true:false'], function (){}

    over this form:

    define(function (require) {
    var has = require("has");
    if(has("some-feature")){
    var m = require("some/module");
    }else{
    var m = require("some/other/module");
    }
    });

    because the second form means that both modules would be picked up by
    the optimizer to be included in the build, which may not be what is
    desired. The first form allows for optimized builds based on the test
    value during build time.

    Furthermore, plugins are already supported in RequireJS builds, so I
    just see this as just another plugin. I did not have to add anything
    special for has plugins, they work like any other plugin.

    I believe these are strong enough reasons to keep with supporting a
    has plugin, and not have a special has global that is usable outside a
    define() call.

    James
  • Bryan Forbes at Jan 14, 2011 at 2:26 pm

    On 1/14/11 12:16 PM, James Burke wrote:
    On Thu, Jan 13, 2011 at 10:45 PM, Kris Zyp wrote:
    Anyway, there is enough pros and cons to each different approach
    (has-plugin, global has() ternary, and require("has") with if/else) that
    I don't really have a strong opinion which is best. I would hope we
    could decide on one though.
    I'm going to answer on this thread since Kris was good about changing
    the subject line, but I have read Rawld's response on the other
    thread.

    I only plan to support a has! plugin. I do not want to create a global
    or special global for this feature. I believe there could be more than
    one type of has plugin (in fact I expect it, I would like to see a web
    tool so you only have to embed the has tests you need and generate a
    plugin module from that). Loading of that specialized has plugin the
    may be on a different path:

    define(['./has!test?true:false', 'global/has!test?true:fase'], function (){})

    By using this approach it does not make one has thing more special
    than the other.

    What is supported in the RequireJS build tool is has("test")
    replacement, and those should happen inside the module's factory
    function. I expect that people who want to opt into it will create a
    local variable (or factory function argument) for the has they want to
    participate in that build optimization:

    define(function(require){
    var has = require('has');
    if (has('test')) {
    //true
    } else {
    //false
    }
    });

    So even though there is special treatment of a has variable inside a
    factory function, that has variable is controlled by the developer,
    and it is a locally scoped value. It also only gets processed if the
    developer creates a has: object in the build profile.

    I prefer this form:

    define(['./has!test?true:false'], function (){}

    over this form:

    define(function (require) {
    var has = require("has");
    if(has("some-feature")){
    var m = require("some/module");
    }else{
    var m = require("some/other/module");
    }
    });
    I'd like to weigh in on this as someone who has used "has" extensively
    in developing an experimental purely feature tested library (uber.js).
    I think using the has plugin for RequireJS is the wrong direction for a
    general purpose library like Dojo. I work better in concrete examples
    so let's build a simple HTML module with two functions: getComputedStyle
    and addClass. Here's how I would define it:

    define(["has/dom"], function(has){
    var module = {};

    if(has("dom-current-style")){
    module.getComputedStyle = function(node){
    return node.currentStyle;
    };
    }else if(has("dom-computed-style")){
    module.getComputedStyle = function(node){
    return node.ownerDocument.defaultView.getComputedStyle(node,
    null);
    };
    }else{
    module.getComputedStyle = function(node){
    return node.style;
    };
    }

    if(has("dom-classlist")){
    module.addClass = function(node, token){
    node.classList.add(token);
    };
    }else{
    module.addClass = function(node, token){
    // addClass from Dojo
    };
    }

    return module;
    });

    Here we have one module file that handles 6 permutations. With the
    "has" plugin, however, you'd have to have 5 module files (ignoring the
    third case in getComputedStyle because I don't think you can combine
    plugin statements; correct me if I'm wrong, though) to do the same:

    currentStyle.js:
    define(function(){
    return function(node){
    return node.currentStyle;
    };
    });

    computedStyle.js:
    define(function(){
    return function(node){
    return node.ownerDocument.defaultView.getComputedStyle(node, null);
    };
    });

    native-classlist.js:
    define(function(){
    return function(node, token){
    node.classList.add(token);
    };
    });

    classlist.js:
    define(function(html){
    return function(node, token){
    // code from dojo.addClass
    };
    });

    html.js:
    define(["has!dom-current-style?./currentStyle:./computedStyle",
    "has!dom-classlist?./native-classlist:./classlist"],
    function(getComputedStyle, addClass){
    return {
    getComputedStyle: getComputedStyle,
    addClass: addClass
    };
    }
    );

    I, for one, don't want to maintain 5 module files for this fairly simple
    case (and those 5 module files don't even cover 2 permutations which the
    single module does). This gets compounded further the more has tests
    you do. Off the top of my head, I know setSelectable, setOpacity and
    getOpacity, and byId can all be feature detected. And this is only the
    html module.

    "But can't we ignore the case of currentStyle and native-classlist since
    currentStyle is IE only and doesn't support classList anyway?" Once we
    drop into that logic we are no longer detecting features but detecting
    browsers and a toolkit like Dojo can't afford to do that. How many
    times have we had to make a minor release of Dojo because a new version
    of a browser was released and our browser inferences were wrong for the
    new browser? If we want to do feature detection properly and
    future-proof ourselves as much as possible, we need to do it right and
    make it as easy to maintain as possible.

    - --
    Bryan Forbes
    http://www.reigndropsfall.net

    GPG Fingerprint
    3D7D B728 713A BB7B B8B1 5B61 3888 17E0 70CA 0F3D
  • James Burke at Jan 14, 2011 at 2:33 pm
    Bryan, I agree, the use case you provide does not need a has plugin,
    and the current has support in the RequireJS build tool is enough for
    that case.

    For cases where it is a much more coarser check, like perhaps array
    extras, then a has plugin may make more sense. It could be that the
    array extras case may not be the right case either, but if someone did
    want to load a completely different module based on a has test, I
    believe a has plugin is more appropriate than trying to support a
    special global called has.

    It could be though that for Dojo, the has tests it wants to do are
    always internal to the module, and it may not need to use a has plugin
    to decide to load a different module over another.

    James
    On Fri, Jan 14, 2011 at 11:26 AM, Bryan Forbes wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1
    On 1/14/11 12:16 PM, James Burke wrote:
    On Thu, Jan 13, 2011 at 10:45 PM, Kris Zyp wrote:
    Anyway, there is enough pros and cons to each different approach
    (has-plugin, global has() ternary, and require("has") with if/else) that
    I don't really have a strong opinion which is best. I would hope we
    could decide on one though.
    I'm going to answer on this thread since Kris was good about changing
    the subject line, but I have read Rawld's response on the other
    thread.

    I only plan to support a has! plugin. I do not want to create a global
    or special global for this feature. I believe there could be more than
    one type of has plugin (in fact I expect it, I would like to see a web
    tool so you only have to embed the has tests you need and generate a
    plugin module from that). Loading of that specialized has plugin the
    may be on a different path:

    define(['./has!test?true:false', 'global/has!test?true:fase'], function (){})

    By using this approach it does not make one has thing more special
    than the other.

    What is supported in the RequireJS build tool is has("test")
    replacement, and those should happen inside the module's factory
    function. I expect that people who want to opt into it will create a
    local variable (or factory function argument) for the has they want to
    participate in that build optimization:

    define(function(require){
    ? ? var has = require('has');
    ? ? if (has('test')) {
    ? ? ? ? //true
    ? ? } else {
    ? ? ? ? //false
    ? ? }
    });

    So even though there is special treatment of a has variable inside a
    factory function, that has variable is controlled by the developer,
    and it is a locally scoped value. It also only gets processed if the
    developer creates a has: object in the build profile.

    I prefer this form:

    define(['./has!test?true:false'], function (){}

    over this form:

    define(function (require) {
    ?var has = require("has");
    ?if(has("some-feature")){
    ? ? var m = require("some/module");
    ?}else{
    ? ? var m = require("some/other/module");
    ?}
    });
    I'd like to weigh in on this as someone who has used "has" extensively
    in developing an experimental purely feature tested library (uber.js).
    I think using the has plugin for RequireJS is the wrong direction for a
    general purpose library like Dojo. ?I work better in concrete examples
    so let's build a simple HTML module with two functions: getComputedStyle
    and addClass. ?Here's how I would define it:

    define(["has/dom"], function(has){
    ? ?var module = {};

    ? ?if(has("dom-current-style")){
    ? ? ? ?module.getComputedStyle = function(node){
    ? ? ? ? ? ?return node.currentStyle;
    ? ? ? ?};
    ? ?}else if(has("dom-computed-style")){
    ? ? ? ?module.getComputedStyle = function(node){
    ? ? ? ? ? ?return node.ownerDocument.defaultView.getComputedStyle(node,
    null);
    ? ? ? ?};
    ? ?}else{
    ? ? ? ?module.getComputedStyle = function(node){
    ? ? ? ? ? ?return node.style;
    ? ? ? ?};
    ? ?}

    ? ?if(has("dom-classlist")){
    ? ? ? ?module.addClass = function(node, token){
    ? ? ? ? ? ?node.classList.add(token);
    ? ? ? ?};
    ? ?}else{
    ? ? ? ?module.addClass = function(node, token){
    ? ? ? ? ? ?// addClass from Dojo
    ? ? ? ?};
    ? ?}

    ? ?return module;
    });

    Here we have one module file that handles 6 permutations. ?With the
    "has" plugin, however, you'd have to have 5 module files (ignoring the
    third case in getComputedStyle because I don't think you can combine
    plugin statements; correct me if I'm wrong, though) to do the same:

    currentStyle.js:
    define(function(){
    ? ?return function(node){
    ? ? ? ?return node.currentStyle;
    ? ?};
    });

    computedStyle.js:
    define(function(){
    ? ?return function(node){
    ? ? ? ?return node.ownerDocument.defaultView.getComputedStyle(node, null);
    ? ?};
    });

    native-classlist.js:
    define(function(){
    ? ?return function(node, token){
    ? ? ? ?node.classList.add(token);
    ? ?};
    });

    classlist.js:
    define(function(html){
    ? ?return function(node, token){
    ? ? ? ?// code from dojo.addClass
    ? ?};
    });

    html.js:
    define(["has!dom-current-style?./currentStyle:./computedStyle",
    ? ? ? ?"has!dom-classlist?./native-classlist:./classlist"],
    ? ?function(getComputedStyle, addClass){
    ? ? ? ?return {
    ? ? ? ? ? ?getComputedStyle: getComputedStyle,
    ? ? ? ? ? ?addClass: addClass
    ? ? ? ?};
    ? ?}
    );

    I, for one, don't want to maintain 5 module files for this fairly simple
    case (and those 5 module files don't even cover 2 permutations which the
    single module does). ?This gets compounded further the more has tests
    you do. ?Off the top of my head, I know setSelectable, setOpacity and
    getOpacity, and byId can all be feature detected. ?And this is only the
    html module.

    "But can't we ignore the case of currentStyle and native-classlist since
    currentStyle is IE only and doesn't support classList anyway?" ?Once we
    drop into that logic we are no longer detecting features but detecting
    browsers and a toolkit like Dojo can't afford to do that. ?How many
    times have we had to make a minor release of Dojo because a new version
    of a browser was released and our browser inferences were wrong for the
    new browser? ?If we want to do feature detection properly and
    future-proof ourselves as much as possible, we need to do it right and
    make it as easy to maintain as possible.

    - --
    Bryan Forbes
    http://www.reigndropsfall.net

    GPG Fingerprint
    3D7D B728 713A BB7B B8B1 ?5B61 3888 17E0 70CA 0F3D
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.11 (Darwin)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

    iEYEARECAAYFAk0wo3AACgkQOIgX4HDKDz3yMQCfU02OWmx2aZKXFQv8qAWEj14r
    pokAnRJko8JM2VjhXfDugPfeYUCsOOx6
    =vnxG
    -----END PGP SIGNATURE-----
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Rawld Gill at Jan 14, 2011 at 3:21 pm
    Bryan--thanks for adding expert has experience to this thread.
    On Friday 14 January 2011 11:33:24 James Burke wrote:
    Bryan, I agree, the use case you provide does not need a has plugin,
    and the current has support in the RequireJS build tool is enough for
    that case.
    So Bryan, one of the creators of has.js and an expert JavaScript programmer
    didn't immediately see how to use the has plugin correctly...
    For cases where it is a much more coarser check, like perhaps array
    extras, then a has plugin may make more sense. It could be that the
    array extras case may not be the right case either,
    ...And even James, who invented the has plugin, does not have an iron-clad
    example he really believes in.

    Which provides evidence (not proof) of my point: the has plugin adds
    complexity.
    but if someone did
    want to load a completely different module based on a has test, I
    believe a has plugin is more appropriate than trying to support a
    special global called has.
    That's a straw man argument: the choice is not necessarily against a special
    global, to wit...

    define([require("has")["someFeature"]?"some/module":"some/other/module"],
    //...

    Yes, the loader must make sure require("has") (or, e.g.,
    require("has/someHasModule")) answers with a real module. But this could be
    solved giving has special status in the loader...which transfers complexity
    from users (many) to loader builders...you and me, James :).

    Initially I was a huge fan of plugins and very impressed with the idea. I
    admit this. But, even the text plugin isn't required: you can easily see text
    by looking at the filetype. If I could figure out how to do i18n neatly
    without plugins, I'd propose doing away with the whole idea. But, they do
    solve that problem better than anything I can think of currently.

    We must beat back complexity. We must make APIs minimal and orthogonal. We
    must be willing, at this early stage of dojo 2.0 (and, I think, requirejs and
    bdLoad) to be open to changing course.

    Note carefully, than I am not advovating an absolute decision about the has
    plugin since James brought up the global variable issue. I just want a fair
    and thorough discussion of the design options, including real use cases,
    before we pick one.

    Best,
    Rawld

    It could be though that for Dojo, the has tests it wants to do are
    always internal to the module, and it may not need to use a has plugin
    to decide to load a different module over another.

    James
    On Fri, Jan 14, 2011 at 11:26 AM, Bryan Forbes wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1
    On 1/14/11 12:16 PM, James Burke wrote:
    On Thu, Jan 13, 2011 at 10:45 PM, Kris Zyp wrote:
    Anyway, there is enough pros and cons to each different approach
    (has-plugin, global has() ternary, and require("has") with if/else)
    that I don't really have a strong opinion which is best. I would hope
    we could decide on one though.
    I'm going to answer on this thread since Kris was good about changing
    the subject line, but I have read Rawld's response on the other
    thread.

    I only plan to support a has! plugin. I do not want to create a global
    or special global for this feature. I believe there could be more than
    one type of has plugin (in fact I expect it, I would like to see a web
    tool so you only have to embed the has tests you need and generate a
    plugin module from that). Loading of that specialized has plugin the
    may be on a different path:

    define(['./has!test?true:false', 'global/has!test?true:fase'], function
    (){})

    By using this approach it does not make one has thing more special
    than the other.

    What is supported in the RequireJS build tool is has("test")
    replacement, and those should happen inside the module's factory
    function. I expect that people who want to opt into it will create a
    local variable (or factory function argument) for the has they want to
    participate in that build optimization:

    define(function(require){
    var has = require('has');
    if (has('test')) {
    //true
    } else {
    //false
    }
    });

    So even though there is special treatment of a has variable inside a
    factory function, that has variable is controlled by the developer,
    and it is a locally scoped value. It also only gets processed if the
    developer creates a has: object in the build profile.

    I prefer this form:

    define(['./has!test?true:false'], function (){}

    over this form:

    define(function (require) {
    var has = require("has");
    if(has("some-feature")){
    var m = require("some/module");
    }else{
    var m = require("some/other/module");
    }
    });
    I'd like to weigh in on this as someone who has used "has" extensively
    in developing an experimental purely feature tested library (uber.js).
    I think using the has plugin for RequireJS is the wrong direction for a
    general purpose library like Dojo. I work better in concrete examples
    so let's build a simple HTML module with two functions: getComputedStyle
    and addClass. Here's how I would define it:

    define(["has/dom"], function(has){
    var module = {};

    if(has("dom-current-style")){
    module.getComputedStyle = function(node){
    return node.currentStyle;
    };
    }else if(has("dom-computed-style")){
    module.getComputedStyle = function(node){
    return node.ownerDocument.defaultView.getComputedStyle(node,
    null);
    };
    }else{
    module.getComputedStyle = function(node){
    return node.style;
    };
    }

    if(has("dom-classlist")){
    module.addClass = function(node, token){
    node.classList.add(token);
    };
    }else{
    module.addClass = function(node, token){
    // addClass from Dojo
    };
    }

    return module;
    });

    Here we have one module file that handles 6 permutations. With the
    "has" plugin, however, you'd have to have 5 module files (ignoring the
    third case in getComputedStyle because I don't think you can combine
    plugin statements; correct me if I'm wrong, though) to do the same:

    currentStyle.js:
    define(function(){
    return function(node){
    return node.currentStyle;
    };
    });

    computedStyle.js:
    define(function(){
    return function(node){
    return node.ownerDocument.defaultView.getComputedStyle(node,
    null); };
    });

    native-classlist.js:
    define(function(){
    return function(node, token){
    node.classList.add(token);
    };
    });

    classlist.js:
    define(function(html){
    return function(node, token){
    // code from dojo.addClass
    };
    });

    html.js:
    define(["has!dom-current-style?./currentStyle:./computedStyle",
    "has!dom-classlist?./native-classlist:./classlist"],
    function(getComputedStyle, addClass){
    return {
    getComputedStyle: getComputedStyle,
    addClass: addClass
    };
    }
    );

    I, for one, don't want to maintain 5 module files for this fairly simple
    case (and those 5 module files don't even cover 2 permutations which the
    single module does). This gets compounded further the more has tests
    you do. Off the top of my head, I know setSelectable, setOpacity and
    getOpacity, and byId can all be feature detected. And this is only the
    html module.

    "But can't we ignore the case of currentStyle and native-classlist since
    currentStyle is IE only and doesn't support classList anyway?" Once we
    drop into that logic we are no longer detecting features but detecting
    browsers and a toolkit like Dojo can't afford to do that. How many
    times have we had to make a minor release of Dojo because a new version
    of a browser was released and our browser inferences were wrong for the
    new browser? If we want to do feature detection properly and
    future-proof ourselves as much as possible, we need to do it right and
    make it as easy to maintain as possible.

    - --
    Bryan Forbes
    http://www.reigndropsfall.net

    GPG Fingerprint
    3D7D B728 713A BB7B B8B1 5B61 3888 17E0 70CA 0F3D
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.11 (Darwin)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

    iEYEARECAAYFAk0wo3AACgkQOIgX4HDKDz3yMQCfU02OWmx2aZKXFQv8qAWEj14r
    pokAnRJko8JM2VjhXfDugPfeYUCsOOx6
    =vnxG
    -----END PGP SIGNATURE-----
    _______________________________________________
    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
  • Bill Keese at Jan 15, 2011 at 6:10 pm

    Rawld wrote:

    the choice is not necessarily against a special
    global, to wit...

    define([require("has")["someFeature"]?"some/module":"some/other/module"],
    //...

    ...Initially I was a huge fan of plugins ... We must beat back
    complexity....


    I'm lost... you are suggesting this, right?

    define([require("has")["someFeature"]?"some/module":"some/other/module"],


    How is that different from a has plugin? I read over
    http://requirejs.org/docs/optimization.html#hasjs which is talking about
    removing unneeded code branches, that seems different than this whole
    discussion about conditional loading of modules.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110116/6dd9f7d3/attachment.htm
  • Rawld Gill at Jan 15, 2011 at 7:20 pm

    On Saturday 15 January 2011 15:10:29 Bill Keese wrote:
    Rawld wrote:
    the choice is not necessarily against a special
    global, to wit...

    define([require("has")["someFeature"]?"some/module":"some/other/module"],
    //...

    ...Initially I was a huge fan of plugins ... We must beat back
    complexity....
    I'm lost... you are suggesting this, right?

    define([require("has")["someFeature"]?"some/module":"some/other/module"],


    How is that different from a has plugin?
    Functionally, it is intended to be identical the the requirejs has plugin,
    which is precisely the point: you get the same functionality without having to
    build/teach/doc/mx additional machinery. Unfortunately, making the idea
    actually work may be quite tricky for loader implementers.

    Note: when you say "has plugin", I assume you're talking about the requirejs
    has plugin which is something completely different than the has.js feature
    test machinery or the optimizer that removes has branches based on known
    features. I tried to find a link to it, but I can't find it anywhere. James,
    can you point us to the requirejs has! plugin?

    I read over
    http://requirejs.org/docs/optimization.html#hasjs which is talking about
    removing unneeded code branches, that seems different than this whole
    discussion about conditional loading of modules.
    Right. Removing has branches based on has features known at build-time is
    another issue.

    Best,
    Rawld
  • James Burke at Jan 17, 2011 at 12:24 am

    On Sat, Jan 15, 2011 at 4:20 PM, Rawld Gill wrote:
    Note: when you say "has plugin", I assume you're talking about the requirejs
    has plugin which is something completely different than the has.js feature
    test machinery or the optimizer that removes has branches based on known
    features. I tried to find a link to it, but I can't find it anywhere. James,
    can you point us to the requirejs has! plugin?
    I do not include a has plugin at the moment in the RequireJS repo, and
    I'm thinking I probably should not. Ideally it would be part of the
    has project, or as a separate derivative project that uses the base
    has.js library. I also hope not to maintain it, but I am happy to help
    get it bootstrapped.

    Kris Zyp has done some work for it in his has fork here, but I am not
    sure of the current state of it (I have been meaning to ask Kris about
    it, so Kris, if you are reading, feel free to jump in):
    https://github.com/kriszyp/has.js

    So the only special knowledge in the RequireJS code/repo is the
    has("testName") regexp conversions in the optimizer to true or false
    based on a has object that is configured in a build profile.

    James
  • Kris Zyp at Jan 17, 2011 at 1:42 pm
    I wanted to summarize this discussion again, as I think we can boil it
    down to a set of pros and cons for easier comprehension. First, to be
    clear, I think everyone is agreement that the main form of branching on
    browser's features in Dojo 2.0 should and will be
    if(has(feature)){..}else{...} blocks. This is consistent,
    feature-detect-based, works at runtime and build time, and is already
    supported in RequireJS. The main question is what to do if we need to
    conditionally load module based on features. I believe that such use
    cases should be rare, but potentially important nonetheless. We could
    wait until we have actually encounter a concrete example before making a
    decision if we wanted, but I'll recap anyway.

    As an example I had recently considered, we could have an
    events/listener module that uses addEventListener if available (on DOM
    nodes), but if not leans on an AOP module to track the listeners
    (additional of listeners and removal). One could inline the AOP code in
    our events module, but this is undesirable because it is possible that
    the AOP module is already loaded/used by other code, and so we want to
    reuse this module. (In reality, I don't think we would actually
    conditionally load the AOP module since an events module should be able
    to work on event emitters that don't have addEventListener even in
    environments where node's have addEventListener, but let's pretend, this
    is definitely has potential to be similar to other real use cases).
    There are three options that have been considered for conditional
    loading, and I'll show how each could be used for this scenario. Ideally
    we would choose one to minimize techniques we need to explain and support:

    * Use ternary has() in dependency lists (Rawld has advocated this) like
    define([has("feature")?"a":"b"],...
    Our example events module would be written:
    define([has("dom-addeventlistener") ? null : "./aop"], function(aop){
    var listen;
    if(has("dom-addeventlistener")){
    listen = function(node, event, listener){
    node.addEventListener(event, listener, false);
    };
    }else{
    listen = aop;
    }
    return listen;
    }

    Pros:
    -Uses and combines existing constructs (has() and define statements), so
    easy to write
    -Supports run-time conditional loading
    Cons:
    -Relies on a priori setup of has() global, or "has" module (can't be
    loaded by the module, since it must be synchronously available), and any
    other test module (like has's dom module in this case), thus modules
    either can't express their full dependencies, or must rely on has()
    always being provided by module loaders
    -No analogous mechanism in future ECMA simple modules
    -Typically requires double testing a feature, once in dependency list,
    once in module code that branches

    * has! plugin (James has advocated this, and I wrote a rough prototype
    plugin) like define(["has!feature?a:b"],...
    Our example events module would be written:
    define(["has!dom-addeventlistener?:./aop", "has"], function(aop, has){
    var listen;
    if(has("dom-addeventlistener")){
    listen = function(node, event, listener){
    node.addEventListener(event, listener, false);
    };
    }else{
    listen = aop;
    }
    return listen;
    }

    Pros:
    -Supports run-time conditional loading
    -Can continue to be used in future ECMA simple modules
    Cons:
    -Requires a "new" API to be used, devs need to learn how to use the
    "has!" plugin
    -Typically requires double testing a feature, once in dependency list,
    once in module code that branches


    * require() statements inside if(has()) blocks (I have advocated this),
    like if(has("feature")){require("a")}else{require("b")}
    Our example would be written:
    define(function(require){
    var has = require("has");
    if(has("dom-addeventlistener")){
    listen = function(node, event, listener){
    node.addEventListener(event, listener, false);
    };
    }else{
    listen = require("./aop");
    }
    return listen;
    }

    Pros:
    -Uses existing constructs (has() and require() statements), easy to
    understand
    -The has() test only needs to be written/run once then the dependency is
    expressed naturally within the feature branch block. Intuitively matches
    how we write our normal feature branches.
    -Can continue to be used in future ECMA simple modules (since it doesn't
    do anything at run-time)
    Cons:
    -Does not do run-time conditional loading, this only works at build time
    (dependencies can be omitted for different builds based on the build
    features)
    -Likely will only work with modules that use require() to declare
    dependencies (with AMD this is supported, and the loader finds the
    require()'s to async load deps).

    Anyway, hopefully that is comprehensible and balanced overview of the
    choices. Obviously there are pros and cons to each.
    Thanks,
    Kris

    On 1/15/2011 5:20 PM, Rawld Gill wrote:
    On Saturday 15 January 2011 15:10:29 Bill Keese wrote:
    Rawld wrote:
    the choice is not necessarily against a special
    global, to wit...

    define([require("has")["someFeature"]?"some/module":"some/other/module"],
    //...

    ...Initially I was a huge fan of plugins ... We must beat back
    complexity....
    I'm lost... you are suggesting this, right?

    define([require("has")["someFeature"]?"some/module":"some/other/module"],


    How is that different from a has plugin?
    Functionally, it is intended to be identical the the requirejs has plugin,
    which is precisely the point: you get the same functionality without having to
    build/teach/doc/mx additional machinery. Unfortunately, making the idea
    actually work may be quite tricky for loader implementers.

    Note: when you say "has plugin", I assume you're talking about the requirejs
    has plugin which is something completely different than the has.js feature
    test machinery or the optimizer that removes has branches based on known
    features. I tried to find a link to it, but I can't find it anywhere. James,
    can you point us to the requirejs has! plugin?
    Unless someone else has worked on it, this is *the* has plugin:
    https://github.com/kriszyp/has.js
    I read over
    http://requirejs.org/docs/optimization.html#hasjs which is talking about
    removing unneeded code branches, that seems different than this whole
    discussion about conditional loading of modules.
    Right. Removing has branches based on has features known at build-time is
    another issue.

    Best,
    Rawld
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • James Burke at Jan 17, 2011 at 2:14 pm

    On Mon, Jan 17, 2011 at 10:42 AM, Kris Zyp wrote:
    * require() statements inside if(has()) blocks (I have advocated this),
    like if(has("feature")){require("a")}else{require("b")}
    [snip]
    Pros:
    -Can continue to be used in future ECMA simple modules (since it doesn't
    do anything at run-time)
    It is my understanding this will not work if the code is converted to
    simple modules since a module or use statement needs to be at the top
    of a module, they cannot participate in if/else branches. But if I
    misunderstood, it would be good to be corrected.

    That said I think any Simple Modules-related pros/cons are likely to
    be problematic. It is not clear to me how it will really work (the
    loader APIs still seem very much a draft), but this point in
    particular I think needs to be called out. To me, the sync require("")
    usage maps to Simple Modules use of a module or use statement.
    Anything else needs to effectively be a callback-based ES loader API
    strawman use.

    James
  • Bill Keese at Jan 17, 2011 at 11:32 pm
    Seems like all of these alternatives require that all the has() tests (ex:
    dom-addEventListener) are loaded as part of the bootstrap, so that
    has("feature")
    checks can run synchronously? Not sure if that's scalable. The
    alternative is:

    require(["has/dom"[, function(hasDom){
    define( hasDom("addEventListener") ? [] : ["aop"], ...
    });

    Pete tells me the current suite of checks is small, but it would likely grow
    a lot if dijit tried to use has(). OTOH it would shrink a lot if we split
    off IE as a separate case, rather than testing individually for every IE
    bug.

    Size won't be an issue for customers doing platform specific builds, but
    presumably the majority of our customer won't do that.
    On Tue, Jan 18, 2011 at 3:42 AM, Kris Zyp wrote:

    I wanted to summarize this discussion again, as I think we can boil it
    down to a set of pros and cons for easier comprehension. First, to be
    clear, I think everyone is agreement that the main form of branching on
    browser's features in Dojo 2.0 should and will be
    if(has(feature)){..}else{...} blocks. This is consistent,
    feature-detect-based, works at runtime and build time, and is already
    supported in RequireJS. The main question is what to do if we need to
    conditionally load module based on features. I believe that such use
    cases should be rare, but potentially important nonetheless. We could
    wait until we have actually encounter a concrete example before making a
    decision if we wanted, but I'll recap anyway.

    As an example I had recently considered, we could have an
    events/listener module that uses addEventListener if available (on DOM
    nodes), but if not leans on an AOP module to track the listeners
    (additional of listeners and removal). One could inline the AOP code in
    our events module, but this is undesirable because it is possible that
    the AOP module is already loaded/used by other code, and so we want to
    reuse this module. (In reality, I don't think we would actually
    conditionally load the AOP module since an events module should be able
    to work on event emitters that don't have addEventListener even in
    environments where node's have addEventListener, but let's pretend, this
    is definitely has potential to be similar to other real use cases).
    There are three options that have been considered for conditional
    loading, and I'll show how each could be used for this scenario. Ideally
    we would choose one to minimize techniques we need to explain and support:

    * Use ternary has() in dependency lists (Rawld has advocated this) like
    define([has("feature")?"a":"b"],...
    Our example events module would be written:
    define([has("dom-addeventlistener") ? null : "./aop"], function(aop){
    var listen;
    if(has("dom-addeventlistener")){
    listen = function(node, event, listener){
    node.addEventListener(event, listener, false);
    };
    }else{
    listen = aop;
    }
    return listen;
    }

    Pros:
    -Uses and combines existing constructs (has() and define statements), so
    easy to write
    -Supports run-time conditional loading
    Cons:
    -Relies on a priori setup of has() global, or "has" module (can't be
    loaded by the module, since it must be synchronously available), and any
    other test module (like has's dom module in this case), thus modules
    either can't express their full dependencies, or must rely on has()
    always being provided by module loaders
    -No analogous mechanism in future ECMA simple modules
    -Typically requires double testing a feature, once in dependency list,
    once in module code that branches

    * has! plugin (James has advocated this, and I wrote a rough prototype
    plugin) like define(["has!feature?a:b"],...
    Our example events module would be written:
    define(["has!dom-addeventlistener?:./aop", "has"], function(aop, has){
    var listen;
    if(has("dom-addeventlistener")){
    listen = function(node, event, listener){
    node.addEventListener(event, listener, false);
    };
    }else{
    listen = aop;
    }
    return listen;
    }

    Pros:
    -Supports run-time conditional loading
    -Can continue to be used in future ECMA simple modules
    Cons:
    -Requires a "new" API to be used, devs need to learn how to use the
    "has!" plugin
    -Typically requires double testing a feature, once in dependency list,
    once in module code that branches


    * require() statements inside if(has()) blocks (I have advocated this),
    like if(has("feature")){require("a")}else{require("b")}
    Our example would be written:
    define(function(require){
    var has = require("has");
    if(has("dom-addeventlistener")){
    listen = function(node, event, listener){
    node.addEventListener(event, listener, false);
    };
    }else{
    listen = require("./aop");
    }
    return listen;
    }

    Pros:
    -Uses existing constructs (has() and require() statements), easy to
    understand
    -The has() test only needs to be written/run once then the dependency is
    expressed naturally within the feature branch block. Intuitively matches
    how we write our normal feature branches.
    -Can continue to be used in future ECMA simple modules (since it doesn't
    do anything at run-time)
    Cons:
    -Does not do run-time conditional loading, this only works at build time
    (dependencies can be omitted for different builds based on the build
    features)
    -Likely will only work with modules that use require() to declare
    dependencies (with AMD this is supported, and the loader finds the
    require()'s to async load deps).

    Anyway, hopefully that is comprehensible and balanced overview of the
    choices. Obviously there are pros and cons to each.
    Thanks,
    Kris

    On 1/15/2011 5:20 PM, Rawld Gill wrote:
    On Saturday 15 January 2011 15:10:29 Bill Keese wrote:
    Rawld wrote:
    the choice is not necessarily against a special
    global, to wit...
    define([require("has")["someFeature"]?"some/module":"some/other/module"],
    //...

    ...Initially I was a huge fan of plugins ... We must beat back
    complexity....
    I'm lost... you are suggesting this, right?
    define([require("has")["someFeature"]?"some/module":"some/other/module"],

    How is that different from a has plugin?
    Functionally, it is intended to be identical the the requirejs has plugin,
    which is precisely the point: you get the same functionality without having to
    build/teach/doc/mx additional machinery. Unfortunately, making the idea
    actually work may be quite tricky for loader implementers.

    Note: when you say "has plugin", I assume you're talking about the requirejs
    has plugin which is something completely different than the has.js feature
    test machinery or the optimizer that removes has branches based on known
    features. I tried to find a link to it, but I can't find it anywhere. James,
    can you point us to the requirejs has! plugin?
    Unless someone else has worked on it, this is *the* has plugin:
    https://github.com/kriszyp/has.js
    about
    removing unneeded code branches, that seems different than this whole
    discussion about conditional loading of modules.
    Right. Removing has branches based on has features known at build-time is
    another issue.

    Best,
    Rawld
    _______________________________________________
    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/20110118/3ce4146a/attachment.htm
  • Kris Zyp at Jan 24, 2011 at 10:07 am

    On 1/17/2011 9:32 PM, Bill Keese wrote:
    Seems like all of these alternatives require that all the has() tests
    (ex: dom-addEventListener) are loaded as part of the bootstrap, so
    that has("feature") checks can run synchronously? Not sure if
    that's scalable. The alternative is:
    No, only option #1 requires has be part of the bootstrap. Options #2 and
    #3 both can has() tests as a normal dependency. If you were using
    has/dom, option #2 would use "has/dom!dom-addeventlistener?:./aop" and
    option #3 would use set the has variable to require("has/dom"). In both
    cases "has/dom" can be loaded asynchronously by the module loader.
    Seems like all of these alternatives require that all the has() tests
    (ex: dom-addEventListener) are loaded as part of the bootstrap, so
    that has("feature") checks can run synchronously? Not sure if that's
    scalable. The alternative is:

    require(["has/dom"[, function(hasDom){
    define( hasDom("addEventListener") ? [] : ["aop"], ...
    });
    I don't believe that wouldn't work, since it would be impossible to
    identify the calling script from the define() call since the define()
    looks to see which script is currently executing to identify itself.

    While has.js's detect directory has a number of test files, I am not
    sure we would necessarily want to load modules to get tests. Most of
    these individual tests are small enough that it might actually be better
    to copy and inline them if they aren't going to be heavily reused,
    particularly when the size of the test isn't much more than dependency
    boilerplate. With our example:

    var has = require("has");
    has.add("dom-addeventlistener", !!document.addEventListener);
    if(has("dom-addeventlistener")){

    Adding the test is a single line of code. In most situations it would be
    absurd to load a module just to avoid a single line of code.

    The question of how we depend on "has" is also pertinent to even how we
    do basic if(has()) blocks. While the has! plugin is only pertinent to
    conditionally loaded modules (rarer), referencing has will be extremely
    common in the future.

    We are still faced with the decision about whether or not to make "has"
    be a global variable provided by the bootstrap process. If we do, maybe
    we could at least make our Dojo package less presumptious by having some
    declaration in package.json that indicates the has is required and the
    has script must be executed prior to loading anything else.

    If we make "has" be a proper dependency (and/or the sub-modules/test
    modules like "has/dom"), then do we have the dojo package have a
    dependency on a "has" package, or we do we have our own "dojo/has" module?

    It would be nice to have has() in 1.7, but a decision about how to
    depend on has() would need to be made soon then.
    Kris
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110124/e22d88ee/attachment.htm
  • James Burke at Jan 24, 2011 at 1:23 pm

    2011/1/24 Kris Zyp <kzyp at dojotoolkit.org>:
    If we make "has" be a proper dependency (and/or the sub-modules/test modules
    like "has/dom"), then do we have the dojo package have a dependency on a
    "has" package, or we do we have our own "dojo/has" module?

    It would be nice to have has() in 1.7, but a decision about how to depend on
    has() would need to be made soon then.
    In the interest of moving this along to a decision, I vote:

    Dojo should have its own has module that contains the tests used in
    base and core. Since the tests are small it is OK if we put all of
    them for base and core into one file. Dojox/Dijit can have their own
    module with their own has tests, reference via "./has", or they can
    choose to inline the tests, up to a case-by case basis. They can reuse
    the ones in base/core by referencing "dojo/has".

    dojo/has does not have to start off being a loader plugin. Stand up
    the code, and then if it looks like a loader plugin would be useful,
    then introduce it after a discussion of the specific use case on list.

    Having special knowledge or status for a has variable that operates
    outside a module should be avoided. The less magic variables the
    better. It is not inline with trying to avoid globals, and even if it
    is not a true global, it will cause enough problems for things like
    multiversion support to not be worth it.

    James
  • Kris Zyp at Jan 24, 2011 at 4:20 pm
    Another possibility is to just inline the has() implementation. It is
    only a few dozen bytes, barely any more than require'ing dojo/has. For
    example:
    define([], function(){
    // inline the test
    var tests = {
    "dom-addeventlistener": document.addEventListener
    };
    // inline has() itself
    var has = function(test){
    return tests[test];
    };
    if(has("dom-addeventlistener")){
    ...
    }

    In fact when there is only a single has() check, you could cheat and
    just put the test as the return value of has(), and it might actually be
    fewer bytes than listing a dependency.

    This would also make it possible to use Rawld's suggested has() ternary
    approach to conditional module without has() being provided by the
    bootstrap, making it much more appealing.

    Thanks,
    Kris

    On 1/24/2011 11:23 AM, James Burke wrote:
    2011/1/24 Kris Zyp <kzyp at dojotoolkit.org>:
    If we make "has" be a proper dependency (and/or the sub-modules/test modules
    like "has/dom"), then do we have the dojo package have a dependency on a
    "has" package, or we do we have our own "dojo/has" module?

    It would be nice to have has() in 1.7, but a decision about how to depend on
    has() would need to be made soon then.
    In the interest of moving this along to a decision, I vote:

    Dojo should have its own has module that contains the tests used in
    base and core. Since the tests are small it is OK if we put all of
    them for base and core into one file. Dojox/Dijit can have their own
    module with their own has tests, reference via "./has", or they can
    choose to inline the tests, up to a case-by case basis. They can reuse
    the ones in base/core by referencing "dojo/has".

    dojo/has does not have to start off being a loader plugin. Stand up
    the code, and then if it looks like a loader plugin would be useful,
    then introduce it after a discussion of the specific use case on list.

    Having special knowledge or status for a has variable that operates
    outside a module should be avoided. The less magic variables the
    better. It is not inline with trying to avoid globals, and even if it
    is not a true global, it will cause enough problems for things like
    multiversion support to not be worth it.

    James
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Bill Keese at Jan 24, 2011 at 4:58 pm

    On Tue, Jan 25, 2011 at 12:07 AM, Kris Zyp wrote:

    On 1/17/2011 9:32 PM, Bill Keese wrote:

    Seems like all of these alternatives require that all the has() tests (ex:
    dom-addEventListener) are loaded as part of the bootstrap, so that
    has("feature") checks can run synchronously? Not sure if that's scalable.
    The alternative is:


    No, only option #1 requires has be part of the bootstrap. Options #2 and #3
    both can has() tests as a normal dependency. If you were using has/dom,
    option #2 would use "has/dom!dom-addeventlistener?:./aop" and option #3
    would use set the has variable to require("has/dom"). In both cases
    "has/dom" can be loaded asynchronously by the module loader.
    I guess that's true for option #2. For option #3 though, doesn't your code
    example implies that require("has/dom") runs synchronously, since the value
    is used right after the require call?

    define(function(require){
    var has = require("has");

    if(has("dom-addeventlistener")){

    listen = function(node, event, listener){

    node.addEventListener(event, listener, false);

    };

    }else{

    listen = require("./aop");

    }

    return listen;

    }
    At what point is has/dom loaded asynchronously?


    While has.js's detect directory has a number of test files, I am not sure
    we would necessarily want to load modules to get tests. Most of these
    individual tests are small enough that it might actually be better to copy
    and inline them if they aren't going to be heavily reused, particularly when
    the size of the test isn't much more than dependency boilerplate. With our
    example:

    var has = require("has");
    has.add("dom-addeventlistener", !!document.addEventListener);
    if(has("dom-addeventlistener")){

    Adding the test is a single line of code. In most situations it would be
    absurd to load a module just to avoid a single line of code.

    The question of how we depend on "has" is also pertinent to even how we do
    basic if(has()) blocks. While the has! plugin is only pertinent to
    conditionally loaded modules (rarer), referencing has will be extremely
    common in the future.

    We are still faced with the decision about whether or not to make "has" be
    a global variable provided by the bootstrap process. If we do, maybe we
    could at least make our Dojo package less presumptious by having some
    declaration in package.json that indicates the has is required and the has
    script must be executed prior to loading anything else.

    If we make "has" be a proper dependency (and/or the sub-modules/test
    modules like "has/dom"), then do we have the dojo package have a dependency
    on a "has" package, or we do we have our own "dojo/has" module?

    It would be nice to have has() in 1.7, but a decision about how to depend
    on has() would need to be made soon then.
    Kris
    Agreed.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110125/87f6b3d8/attachment.htm
  • Kris Zyp at Jan 24, 2011 at 5:20 pm

    On 1/24/2011 2:58 PM, Bill Keese wrote:

    On Tue, Jan 25, 2011 at 12:07 AM, Kris Zyp <kzyp at dojotoolkit.org
    wrote:
    On 1/17/2011 9:32 PM, Bill Keese wrote:
    Seems like all of these alternatives require that all the has()
    tests (ex: dom-addEventListener) are loaded as part of the
    bootstrap, so that has("feature") checks can run synchronously?
    Not sure if that's scalable. The alternative is:
    No, only option #1 requires has be part of the bootstrap. Options
    #2 and #3 both can has() tests as a normal dependency. If you were
    using has/dom, option #2 would use
    "has/dom!dom-addeventlistener?:./aop" and option #3 would use set
    the has variable to require("has/dom"). In both cases "has/dom"
    can be loaded asynchronously by the module loader.


    I guess that's true for option #2. For option #3 though, doesn't
    your code example implies that require("has/dom") runs synchronously,
    since the value is used right after the require call?

    define(function(require){

    var has = require("has");

    if(has("dom-addeventlistener")){

    listen = function(node, event, listener){

    node.addEventListener(event, listener, false);

    };

    }else{

    listen = require("./aop");

    }

    return listen;

    }


    At what point is has/dom loaded asynchronously?
    When define() is called with a single argument that is a function, the
    module loader (if AMD compliant) does a toString() + plug regex search
    to find require statements and pre-load the dependencies. So "has" or
    "has/dom" would load prior to the execution of the factory function.

    However, now that I am considering the ease and simplicity of inlining
    has(), I think I am actually favoring option #1 (Rawld's proposed
    approach) since that allows us to avoid any bootstrap has() while still
    preserving the intuitiveness of has() expressions in dependency
    declarations.

    Thanks,
    Kris
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110124/6bb68f7c/attachment.htm
  • Bill Keese at Jan 24, 2011 at 5:34 pm
    However, now that I am considering the ease and simplicity of inlining
    has(), I think I am actually favoring option #1 (Rawld's proposed approach)
    since that allows us to avoid any bootstrap has() while still preserving the
    intuitiveness of has() expressions in dependency declarations.
    OK, you mean this one, right?

    define([has("dom-addeventlistener") ? null : "./aop"], function(aop){



    How does that avoid bootstrap has()? Clearly has() and the
    "dom-addeventlistener" test needs to be there before that define() is run...
    is there a require() call wrapping the define?
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110125/a691f00a/attachment.htm
  • Kris Zyp at Jan 24, 2011 at 5:45 pm

    On 1/24/2011 3:34 PM, Bill Keese wrote:

    However, now that I am considering the ease and simplicity of
    inlining has(), I think I am actually favoring option #1 (Rawld's
    proposed approach) since that allows us to avoid any bootstrap
    has() while still preserving the intuitiveness of has()
    expressions in dependency declarations.


    OK, you mean this one, right?

    define([has("dom-addeventlistener") ? null : "./aop"], function(aop){



    How does that avoid bootstrap has()? Clearly has() and the
    "dom-addeventlistener" test needs to be there before that define() is
    run... is there a require() call wrapping the define?
    (function(){

    var tests = {
    "dom-addeventlistener": document.addEventListener
    };
    // inline has() itself
    function has(test){
    return tests[test];
    };
    define([has("dom-addeventlistener") ? null : "./aop"], function(aop){

    ...
    });
    })();

    or if you are trying to save bytes:

    (function(){
    function has(){
    return document.addEventListener;
    };
    define([has("dom-addeventlistener") ? null : "./aop"], function(aop){

    ...

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110124/8f04b6d1/attachment.htm
  • Rawld Gill at Jan 24, 2011 at 6:08 pm

    On Monday 24 January 2011 07:07:26 Kris Zyp wrote:
    It would be nice to have has() in 1.7, but a decision about how to
    depend on has() would need to be made soon then.
    Kris
    Kris, thanks for your good summary a few messages back. I'm following, but
    haven't formed a hard opinion yet. I guess I'll think out loud just a little:

    It would be nice to just write code and be able to assume that every has
    feature test ever needed was instantly and always available without having to
    think about it.

    For dev, this means ensuring all the prepackaged has tests from the has
    project + all special has tests that have ever been written by, e.g., the dojo
    project, are automatically injected as part of the (e.g.) dojo package
    load...or, even, loader bootstrap. Since its dev on a localhost, it won't
    affect load time noticeably.

    So, for example, say the mobile guys need some feature test that doesn't exist
    yet. They just put the test in the dojo has "catalog" (for lack of a better
    word) and, presto, the next time you load an unbuilt dojo package, the test is
    there. No adding to deps lists, no plugins, no loader config...it just works
    as part of the package boot.

    You could get access to the has function by either including in a deps list,
    deciding to add it as a property the loader or the package module, or as a
    global variable.

    For release, the optimizer/builder inspects the code and constructs the
    precise has bundle for a particular app.

    This also points to one of my foundational design values: trade size for ease
    of dev so long as any excess size expense can be optimized away during
    release.

    I understand the aversion to another global variable. But, I wonder: are there
    going to be multiple "has.js" vendors? Sometimes, for special things, globals
    are OK. I tend to think has is one of them. That said, I really don't feel too
    strongly about this, and am just as happy making has a module or a property
    off a well-known object (like the package being defined or the loader).

    I think too fine of has selection, e.g.,

    define(["has/dom", "has/this", "has/that"], function(has) {//...

    gets pretty tedious and wordy.

    food for thought...

    Best,
    Rawld
  • Sam foster at Jan 25, 2011 at 4:54 am
    Aren't there some has tests which are inevitably async? What about css
    property testing or font-availability where you have to put elements
    in the document, and measure/examine them before you have a result?
    Maybe this is an edge case which shouldn't inform the design...
    It would be nice to just write code and be able to assume that every has
    feature test ever needed was instantly and always available without having to
    think about it.
    This may depend on the volume of tests. Simple one-liner property
    testing is one thing, but again there are a pile of tests requiring
    e.g. DOM manipulation, loading everything by default may hurt the dev
    scenario. Alternatively you have 'has' test modules, with a core set
    loaded/inlined by default and more exotic ones loaded as dependencies.
    The onus is then on the developer to arrange their code so that they
    aren't using a test until its loaded. Sounds reasonable.
    This also points to one of my foundational design values: trade size for ease
    of dev so long as any excess size expense can be optimized away during
    release.
    yes but at the cost of spooky action from a distance, and mandating a
    build. I'll explain. The area between dev and release is actually many
    shades of grey. There's staging and QA, as well as scenarios where dev
    necessitates xdomain loading from the outset. I had hoped with the new
    loader(s) we could get to a situation where dev and final release
    differ only in degrees of optimization. Perhaps I'm misunderstanding
    and that's what we're talking about. For me the goal is to remove this
    thing where the loader is sync and behaves in one way during dev, but
    behaves in another post-build. Which means that every dev has to be
    able to easily build to validate their work. That means that everyone
    has to think about the build process which defeats the point of the
    ease of dev.
    I understand the aversion to another global variable. But, I wonder: are there
    going to be multiple "has.js" vendors? Sometimes, for special things, globals
    are OK. I tend to think has is one of them.
    has.js is available as a standalone lib right now and unless pete
    withdraws it when we integrate into dojo (why would he?) we have to
    assume that at some point dojo will find itself coexisting on a page
    with another has.js. That's no different from the $ problem other
    libraries suffer, or the console.* problem or any global, but on the
    face it of it, if we're having globals you would expect dojo to claim
    'dojo', dijit to claim 'dijit' and we stretch the point with djConfig.
    My 2c is that if we keep a has global, it should not be inlined into
    our bootstrap and be optionally loaded separately with its own script
    src. Ditto for 'require' and any other global. That gives page authors
    the option to exclude it if its already loaded/provided e.g. by
    another library (or even the browser itself one day). Which to me is
    exactly the kind of agreement and convergence we're shooting for.

    So, I think that means that the loading of 'has' becomes a part of the
    boilerplate to put dojo on the page, perhaps in another data-
    attribute, or a part of djConfig. Alternatively we have different
    bundles and/or the ability to easily create your own core/base dojo -
    which is interesting, but at some point "dojo" has to mean something
    and that's presumably what we're discussing here.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdojo-contributors @
categoriesdojo
postedJan 9, '11 at 1:06p
activeJan 28, '11 at 9:09a
posts70
users13
websitedojotoolkit.org

People

Translate

site design / logo © 2022 Grokbase