[dojo-contributors] Dojo 1.7 Goals: has() and granular dependency lists
rgill at altoviso.com
Mon Mar 14 14:41:05 EDT 2011
I'm working on the 1.7 bootstrap (as discussed at the 2 Mar meeting) and this
work addresses some of the goals Kris outlined. I'll try to get something for
everybody to look at by the next meeting [i've been pulled away from this work
with another issue, but still hopeful on this timetable].
I'll give an outline of this work below. You'll see that there are lots of
design decision points. My idea here is to get something working and then we
can debate any critical decision points and modify code accordingly. I'm using
my best judgment at each point, but *not* saying "this is the way it will be".
Here are the main points of the design/impl:
Today, we have a single bootstrap, dojo.js, that is used for various
environments (browser, rhino, etc.). This will be replaced with environment-
specific bootstraps. We can decide the names later, but, for example:
1. dojo.js: generic browser hosted dojo that includes AMD loader and back
compat layer to sync load via dojo.provide/require.
2. main-browser: generic browser hosted dojo that can be loaded by any AMD
loader; I'll ensure that RequiresJs and bdLoad work.
3. main-node: node-hosted dojo that can be loaded by AMD loader in node.
Granularity: (this dovetails with Kris's goals)
Today, the boot sequence includes lots of functionality that is not possible
to exclude. The big ones are the sync loader, DOMContentLoaded
detection/processing, unload detection/processing, and browser sniffing. But
there's also small stuff like console guarantee, OpenAjax registration, etc.
Each chunk of functionality must be bracketed in a way that it can be
excluded. There are three ways to bracket code:
* pragmas--I want to avoid these
* separate AMD module
I am refactoring (dojo.js, bootstrap.js, hostenv_*.js, loader.js) into four
* dojo bootstrap
* browser sniffing
* DOMContentLoaded detection/processing
* unload detection/processing
Smaller things like console guarantee are bracketed by has.js; e.g.
My overarching design goal here is to refactor orthogonal features into
I'm using has.js throughout the new bootstrap, and there are lots of design
points to debate with has.js--I've had several with myself :) That said,
here's my current plan.
The module dojo/has will implement has, that is, the function has and its
methods, *not* the feature tests. The implementation is taken from the has.js
project with the exception of the obvious things like the lengthy DOM test
that is not needed for a browser-only application. I'll also provide an
alternate module that simply aliases a preexisting global has.
The has.js feature tests are copied into a directory and made AMD loadable.
(Basically what Kris has already done, but, unconditionally AMD modules).
An additional feature test module is included, namely "dojo", for things like
The *source version* unconditionally loads many of the has feature test
modules (I haven't figured out which ones yet). This makes it easy to write
code using has.js...the feature test is already loaded.
Built version of dojo and/or apps will...
* discard all unused has feature tests
* aggregate all feature tests into a single module
* discard all build-time-known has applications and fold code accordingly
* (optionally) rename the lengthy has feature names to use integers
The key benefits of this design:
* minimizes complexity writing code (the test is already there; just use it)
* minimizes size for release code (no unused tests are included)
Back compat to sync mode:
We need to support dojo.provide/require for the 1.x line. *Please* correct me
if I'm wrong, dropping this support would make things better.
Therefore, optionally but by default, dojo boot will include a new impl of
dojo.provide/require that will slip the loader into and out of sync mode and
be 100% compatible with the current impl of these functions. In short, 1.6
simulated AMD; 1.7 will simulate dojo.provide/require.
You can see there are lots of moving parts. I've done this a couple of times
before (sans has.js) with my dojo-sie project, so I think it can be done.
On Friday 11 March 2011 07:10:06 Kris Zyp wrote:
> There are a couple of additional overarching goals that I would like to
> see pursued in 1.7. First, we should start using the has() pattern for
> feature detection branching in our code. Here is the ticket for (and
> explaining) this enhancement:
> Second, as our AMD support will be improved in 1.7, we should start
> using more precise dependency lists to facilitate highly optimized
> builds (only what is needed) and fewer runtime property lookups:
> I don't think the entirety of the Dojo codebase necessarily needs to be
> upgraded to these two coding improvements, but we should try to perform
> these upgrades when possible on code that is actively maintained or
> developed, or heavily used modules.
> Also, if anyone is interested here is patch for adding a module for
> supporting native JSON parsing (using the techniques listed above):
More information about the dojo-contributors