On Wed, Feb 8, 2012 at 14:34, James Burke <[email protected]> wrote:
> On Wed, Feb 8, 2012 at 6:53 AM, Patrick Mueller <[email protected]> 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
