incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Mueller <>
Subject Re: Work Items for 1.5.0 - unified JS
Date Wed, 08 Feb 2012 20:21:20 GMT
On Wed, Feb 8, 2012 at 14:34, James Burke <> wrote:

> On Wed, Feb 8, 2012 at 6:53 AM, Patrick Mueller <> wrote:
> > - almond currently doesn't throw exceptions when undefined modules are
> > require()'d.  This is a very bad thing.  There's currently a bug open on
> > this at GitHub [2], which you should chime in on, as James is for some
> > reason reticent about fixing it.
> The bug is still open. It will restrict the ways in with almond may be
> used, but I am open to narrowing that focus. So feedback in that bug
> is encouraged.

Let's move the bug conversation to the bug.  Currently, the code does not
"fail fast" like it does in other CJS environments, and that's a problem.
 Also, how do you distinguish a module that didn't load, from a module
which does `module.exports = null`, for instance.

> Node's require is not suitable for use in the browser, in particular
> the lack of a callback require really hurts, and loader plugins help
> deal with the async nature of resources loading in the browser.

Not a problem, because Cordova isn't a "browser".  A significant amount of
code that makes up the app must be available immediately; sometimes all of
it, as some platform owners are leery of allowing apps to download "live
code".   Being able to load a "wad" of - let's call them 'packages' - at
once - like a Dojo layer (my understanding of a dojo layer anyway) - is
something that some apps may want to (and be allowed to) do.  But that's
way different from loading individual modules in an async fashion.

> The ability to inline text templates via the text plugin in builds is
> really handy.

The ability load resources in a JavaScript program is great.  The current
AMD mechanism, using module id's which have cruft prefixed with them,
renders your modules unusable in node (without some kind of AMD
super-wrapper).  Resource loading either shouldn't require crufty prefixes
on the module name - require("./package.json") does "the right thing" (for
me, returns JSON.parse() of the contents) - or it should be done with a
different API: module.loadResource("./package.json").

Don't get me started on the "has" or "domReady" plugins!!!

> > * given the above, I'd prefer that we own our own AMD-lite runtime.
> >  Eventually, I'd like to have node's "node_modules" dynamic runtime
> module
> > look up as well ...
> I recently added an "npmrel" task to volo:

Looks like this is rewriting source code to massage the require() string
arguments in the source.  To me, that's a last-resort option.   Doesn't
work if someone dynamically generates their module names used with
require(), for instance.  Adding an additional path search up
"node_modules" subdirectories would work fine as well, since we have all
the modules available at runtime; I understand this is huge issue for async
module loading though.  Again, that's not a requirement for Cordova.

> Insert the standard disclaimer: not all node/npm code is suitable for
> use in the browser, you may need to contact the original code author
> for slight modifications, since they may not have intended browser
> usage.

ha!  I guess the standard disclaimer is required, we don't want people
thinking they can run express in their Cordova app, eh?  That is, until we
actually support it!  Zing!

> Unfortunately I have not looked at the latest cordova code, but I do
> plan on making cordova-based apps that use an AMD loader. In
> particular ones that can use an 'env' plugin to load the right
> adapters/plugins for android vs ios vs whatever. So I am happy to test
> out any solution that allows me to run my own AMD shim (or full
> loader) that at least allows for loader plugins.

Ya, I think I've already brought up the fact that IBM is certainly
interested in using Dojo w/Cordova, and it seems like the right approach is
to allow someone to provide an "AMD-lite" compatible runtime which would be
used instead of ours.  Compatible means it can do way more than our
AMD-lite impl.  So when you do that - indicate you are using require.js or
Dojo - you can of course use all your enhanced AMD stuff.  There are a
variety of ways to slice this problem - your help will be greatly
appreciated when it comes to figuring out how we make this happen.

Perhaps it's time to define "AMD-lite" runtime somewhere?  What do they
call these in Java - profiles?  (CLDC, MIDP, CDC, etc - it has happily been
too many years for me to remember).  The odd thing is this "AMD-lite"
doesn't provide ANY async semantics; it's really CJS +
define(fully-qualified-module-id, moduleFactoryFunction),  Isn't that what
node ended up supporting for a little while?  Why did they remove it?
 Perhaps we could provide a marker in case someone needs to know, at
runtime, they're using AMD-lite: setting define.amdlite =
{something-not-null} or define.amd.lite = {something-not-null}.  In any
case, I think calling this "AMD-lite" feels right to me.  Or maybe SMD -
synchronous module definition (kinda a different way of looking at CJS's
old "transport" specs).

> > * Has anyone thought about making all this work via npm (or equivalent)
> > somehow?  ...
> The aforementioned volo can install code from github, or any url that
> is to a tar.gz file, and allows setup of projects that have a certain
> build style via project templates on github. If the project implements
> a package.json 'amd' property, then any project dependencies added to
> it can be converted to the wrapped style.
> Just mentioning it as a tool that may help build up phonegap projects,
> at least for ones that want a particular style. volo also allows
> installing new 'commands' for it, so for example, you could come up
> with a set of phonegap specific commands for it. The other plus is
> that it is designed to be delivered as a single file -- someone could
> take it, bundle a set of different default commands and deliver that
> JS file for others to use that has built in phonegap-specific
> functionality.

Interesting; this veers into the whole "what is the 'cordova' command-line
program, and what does it do?" discussion.

I don't have much interest in getting modules' source files massaged, but I
suspect there's lots of other things common coding activities that could be
shared - calling compressors, file-collectors, AMD-wrappers, inliners, etc.
 I'll take a look at volo ...

> I get lost in the amount of bugmail for this project, so I end up not
> checking this list that often. Maybe I need to do better filters. But
> always feel free to ping me to look at a thread/repo if it would be
> helpful.

Will try to remember.  I appreciate your contributions.

Patrick Mueller

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