incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Mueller <>
Subject CommonJS and AMD (and, not or)
Date Thu, 08 Dec 2011 16:34:02 GMT
Time to stir the old CommonJS vs AMD wasp's nest again.  No real questions
here, more of a status/brain-dump from me.

One thing that may not have been clear from previous discussions, is that
I'm actually pro-AMD when it comes to using the AMD boilerplate as a
transport mechanism.  Basically, I'm one of those people (the only one?)
who is happy with a work-flow of:

* author your module in CoffeeScript
* when you module changes, your magic auto-builder converts the
CoffeeScript to JS, then wraps the module in AMD boilerplate

My AMD API usage is minimal; all the modules I generate have the following

    define(insert-module-id-here, function(require,exports,module) {

I never specify the dependency array.  dependencies are retrieved via calls
to require()in the common-js-authored-module-here section.  I also,
currently, make use of the pattern to specify what's exported, via the
node-compatible pattern of:

    module.exports = blah-blah

I only ever use require() in the following form:


I'm actually doing this, right now, in an internal project, and am quite
happy with the work-flow. If you're curious, the "build" takes less than a
second to run, with some latency for determining when source files have
changed.  And, I'm using James Burke's almond AMD runtime as my module
runtime system - .

I will likely be converting weinre to this style soon, also using almond.
 James was kind enough to fix a few bugs in almond yesterday that make me
quite happy with using this as a module runtime system for deployed
applications - and for me, at development-time as well.

I have an outstanding request on the AMD-implementors ml - - to
discuss how to consume non-trivial node.js-styled package/module directory
trees.  This is fairly important to me.  If we can't get this sort of
functionality into whatever AMD loader story we might end up with, I'd want
to "extend" that AMD loader story so that it CAN support it.  To me, today,
that would mean forking almond into Cordova and extending it there.

I'm way more interested in consuming existing and future npm packages than
I am in codifying our modules as npm compatible, but would like that too.
 Meaning, if we have to, I can live with using AMD APIs and patterns in
Cordova code that aren't portable to node.js, but would rather we didn't.

Patrick Mueller

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message