Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of pmuellr@gmail.com designates
 209.85.210.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAHgY_icbiPtnyXGjwqF63rKQZsHK0=+PpsotH2DcS2kN4ijt8Q@mail.gmail.com>
References: 
 <CACAoQH1saCyT+eyt3605hEzwRd34y-uvMWcpUp64oUqkU24Eow@mail.gmail.com>
	<CB56E9C9.4BE0%fil@adobe.com>
	<CACAoQH3MSgmy7kjHeh8006rO6BsbShvDf+B3a1WVZPG6iG4YbQ@mail.gmail.com>
	<CAHgY_icbiPtnyXGjwqF63rKQZsHK0=+PpsotH2DcS2kN4ijt8Q@mail.gmail.com>
Date: Wed, 8 Feb 2012 15:21:20 -0500
Message-ID: 
 <CACAoQH2Y5Gp390nTVcX_T4g_HYKfO_V+sozaAaQpjKn8ao+0gg@mail.gmail.com>
Subject: Re: Work Items for 1.5.0 - unified JS
From: Patrick Mueller <pmuellr@gmail.com>
To: callback-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=14dae9340aed7da60604b879a383

--14dae9340aed7da60604b879a383
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Feb 8, 2012 at 14:34, James Burke <jrburke@gmail.com> wrote:

> On Wed, Feb 8, 2012 at 6:53 AM, Patrick Mueller <pmuellr@gmail.com> 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:
> https://github.com/volojs/volo/blob/master/volo/npmrel/doc.md


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
http://muellerware.org

--14dae9340aed7da60604b879a383--