Universal Feature Detection

[Kris Kowal]

On Wed, Apr 29, 2009 at 5:30 AM, David-Sarah Hopwood
<david-sarah at jacaranda.org> wrote:
> David Foley wrote:
>> Please forgive me if I'm polluting the list, and re-direct me if I am,
>> but considering that  there has been so much focus on browser
>> implementation,  that JavaScript is also employable in various
>> 'environments' (IDE's, Servers etc.) and that all of these environments
>> avail different features to developers, that a universal / standard
>> feature detection API, perhaps through a standardised global Environment
>> object, would be prudent.
>>
>> Are there any plans to do such?
>
> There will probably be some kind of module system in ES-Harmony
> (which will be prototyped before then). It would make sense for that
> to support querying whether a given module is available, its version,
> and other metainformation about it.

Ihab Awad and I made an initial proposal for a module system for
Harmony in January, and presented it to TC39.

Proposal: http://docs.google.com/Doc?id=dfgxb7gk_34gpk37z9v&hl=en
Presentation: http://docs.google.com/Presentation?docid=dcd8d5dk_0cs639jg8&hl=en

Since then, we've been working closely with a group called ServerJS
that is creating a standard library for server-side JavaScript, with
participants working on prototypes for {Spider,Trace}monkey
(Flusspferd, GPSEE), V8 (v8cgi, k7), and Rhino (Helma NG, Persevere,
Narwhal).  They've converged on a module system specification that is
very close in form to the initial phase of our proposal (that is,
without syntactic sugar). The proposal and links to the relevant
discussions, which have been extensive, are on the Moz wiki:

https://wiki.mozilla.org/ServerJS/Modules/SecurableModules
https://wiki.mozilla.org/ServerJS/Modules
https://wiki.mozilla.org/ServerJS

The proposal does not require augmentation to the global name space,
but it might be desirable.  In the proposal, there's a "require" free
variable in the module, and various prototypes inject the free
variable into the module's scope, some as an argument to the module
factory function, some as a member of a fresh context object begotten
of global.  So, within modules, there's no need for a global variable.
 There are a couple known options for loading the "main", or initial
module.  One of them is to add a require method to the global object.
Another is to introduce a variant of the <script> tag that loads a
module instead of a global script.  Chiron, my client-side prototype,
uses a script tag to bootstrap a module loader and loads the module in
the <script src> query string.

Regarding feature testing, the module system might be useful since the
"platform", albeit browser, could provide features as modules, in
which case calling "require" on that module's identifier would throw
an error.  Some prototypes have a "require.isLoaded(id)" method that
could be used to test whether modules provided by the platform have
already been loaded, without having to catch a require error.

However, these ideas probably don't obviate the need for a feature
testing system for layout, rendering, event, and other features and
quirks that might not be neatly distinguished based on the
availability of a module.

Kris Kowal