using existing AMD implementations with cordova.js

[Patrick Mueller <pm...@gmail.com>]

"good news everyone"

Just concluded a little experiment to see what happens if we replace the
require.js from cordova-js, with

- almond
- requirejs
- dojo

--------------------------------
testing almond
--------------------------------

https://github.com/jrburke/almond/blob/master/almond.js

add "define.unordered = true" at the bottom of the file to make this work

9 spec failures, all related to require() semantics only

--------------------------------
testing requirejs
--------------------------------

https://github.com/jrburke/requirejs/blob/master/require.js

9 spec failures, similar to or same as the almond.js ones

--------------------------------
testing dojo
--------------------------------

http://dojotoolkit.org/download/ - Dojo Base 1.7.2

nothing works, for some reason "require" and "define" are not defined.

--------------------------------
notes
--------------------------------

- great to see this works, mostly, with at least almond and requirejs.
 We'll need some dojo mojo to figure out what's happening with dojo.

- our require.js adds a "define.remove()" function which no one else
implements.  I'm happy with that, but we should probably make the tests
sensitive to it - only do the "remove" tests if "define.remove()" is present

- issues w/almond and requirejs not throwing exceptions when modules are
multiply defined or missing for require().  I've noted this issue with
almond before, and there's an open bug at almond for it.  Seems like
requirejs is also not doing this.  For this reason alone, I'd recommend
folks not use almond or requirejs as difficult-to-diagnose failures will
occur if, for some reason, a required module is absent.

- the results above were for `jake btest`

- `jake test` fails on all of these due to various sorts of "location",
"navigator", etc not found.  Not quite sure what to do about this, may not
be worth the time to get these "working".

- not quite sure about the best approach to allowing someone to replace our
define() and require() with a different one.  It might be nice if our
implementation just deferred to the existing one (didn't 'install' itself)
if it recognized one was already there - that seems to be the typical
approach with this.  Alternatively, we could build the 'cordova.js' WITHOUT
our require.js in it.

-- 
Patrick Mueller
http://muellerware.org

Re: using existing AMD implementations with cordova.js

[Patrick Mueller <pm...@gmail.com>]

On Wed, Feb 22, 2012 at 16:45, Gord Tanner <go...@tinyhippos.com> wrote:

> define.remove is only in place for unit testing (to remove modules that
> were added for testing purposes)
>

makes sense.  But it also means more tests might be affected than I thought.

The way I've tested these things in the past is to load each suite in a
separate iframe.  Actually, that's how the CJS tests that are in there now
are running.  Not a great story, but ... works.  Maybe if we just relegate
those tests to the CJS side of the testing; it's easy enough to add
additional tests there, with it's weird little "program.js" framework
convention.


> The pathing issues are because our module definitions do not line up with
> the folder layout.  This isn't an issue in the browser with almond or our
> require.js because we just define them in a single file anyways.


I didn't see any pathing issues; `jake test` seemed to fail because some
code - I'm assuming this was in the AMD impls, was expecting `navigator` or
`location` to exist, and it didn't.  May require more work to get some of
these AMD impls to run inside node, but prolly not worth the trouble to
even fix.  I'd say if the `jake btests` work with an AMD impl, works for
me; just don't bother testing with `jake test`.

-- 
Patrick Mueller
http://muellerware.org

Re: using existing AMD implementations with cordova.js

[Gord Tanner <go...@tinyhippos.com>]

define.remove is only in place for unit testing (to remove modules that
were added for testing purposes)

The pathing issues are because our module definitions do not line up with
the folder layout.  This isn't an issue in the browser with almond or our
require.js because we just define them in a single file anyways.



On Wed, Feb 22, 2012 at 2:11 PM, Patrick Mueller <pm...@gmail.com> wrote:

> On Wed, Feb 22, 2012 at 13:51, Filip Maj <fi...@adobe.com> wrote:
>
> > Let's be very careful in recommending anything to our users as our
> > bikeshed require implementation is no where close to what most people
> > consider is "require.js".
> >
>
> I don't think we need to recommend anything.  The various AMD
> implementations will be happy to do some recommending themselves. :-) All
> we need to do is make sure that they can actually work - if there's
> something we need to do to make this happen.  Near as I can tell, little to
> nothing on our part, so far.
>
> And, kinda noted, and I guess this is a personal bias, but I'd recommend
> against using an AMD implementation which does not throw exceptions in
> places you want to "fail fast" - that includes requirejs and almond.
>
>
> > Also we should definitely document what is/isn't supported by our
> require.
> > No async loading, for example.
> >
>
> And so, the definition of "Synchronous Module Definition" begins.  Luckily,
> it will be very short.  :-)
>
>
> > I'll create a JIRA ticket to document that stuff in the README - anywhere
> > else that documentation should exist you guys think?
> >
>
> I think a README is appropriate for now.  Longer term, we will probably
> want to add some actual doc, but ... too early.
>
> --
> Patrick Mueller
> http://muellerware.org
>



-- 
Gord Tanner
Senior Developer / Code Poet
tinyHippos Inc.
@tinyhippos

Re: using existing AMD implementations with cordova.js

[Patrick Mueller <pm...@gmail.com>]

On Wed, Feb 22, 2012 at 13:51, Filip Maj <fi...@adobe.com> wrote:

> Let's be very careful in recommending anything to our users as our
> bikeshed require implementation is no where close to what most people
> consider is "require.js".
>

I don't think we need to recommend anything.  The various AMD
implementations will be happy to do some recommending themselves. :-) All
we need to do is make sure that they can actually work - if there's
something we need to do to make this happen.  Near as I can tell, little to
nothing on our part, so far.

And, kinda noted, and I guess this is a personal bias, but I'd recommend
against using an AMD implementation which does not throw exceptions in
places you want to "fail fast" - that includes requirejs and almond.


> Also we should definitely document what is/isn't supported by our require.
> No async loading, for example.
>

And so, the definition of "Synchronous Module Definition" begins.  Luckily,
it will be very short.  :-)


> I'll create a JIRA ticket to document that stuff in the README - anywhere
> else that documentation should exist you guys think?
>

I think a README is appropriate for now.  Longer term, we will probably
want to add some actual doc, but ... too early.

-- 
Patrick Mueller
http://muellerware.org

Re: using existing AMD implementations with cordova.js

[Filip Maj <fi...@adobe.com>]

Let's be very careful in recommending anything to our users as our
bikeshed require implementation is no where close to what most people
consider is "require.js".

Also we should definitely document what is/isn't supported by our require.
No async loading, for example.

I'll create a JIRA ticket to document that stuff in the README - anywhere
else that documentation should exist you guys think?

On 12-02-22 10:46 AM, "Brian LeRoux" <b...@brian.io> wrote:

>> - our require.js adds a "define.remove()" function which no one else
>> implements.  I'm happy with that, but we should probably make the tests
>> sensitive to it - only do the "remove" tests if "define.remove()" is
>>present
>
>+1
>
>> - issues w/almond and requirejs not throwing exceptions when modules are
>> multiply defined or missing for require().  I've noted this issue with
>> almond before, and there's an open bug at almond for it.  Seems like
>> requirejs is also not doing this.  For this reason alone, I'd recommend
>> folks not use almond or requirejs as difficult-to-diagnose failures will
>> occur if, for some reason, a required module is absent.
>
>
>So we *can* support alternate loaders but we'd recommend just using
>https://github.com/callback/callback-js/blob/master/lib/require.js ??

Re: using existing AMD implementations with cordova.js

[Brian LeRoux <b...@brian.io>]

> - our require.js adds a "define.remove()" function which no one else
> implements.  I'm happy with that, but we should probably make the tests
> sensitive to it - only do the "remove" tests if "define.remove()" is present

+1

> - issues w/almond and requirejs not throwing exceptions when modules are
> multiply defined or missing for require().  I've noted this issue with
> almond before, and there's an open bug at almond for it.  Seems like
> requirejs is also not doing this.  For this reason alone, I'd recommend
> folks not use almond or requirejs as difficult-to-diagnose failures will
> occur if, for some reason, a required module is absent.


So we *can* support alternate loaders but we'd recommend just using
https://github.com/callback/callback-js/blob/master/lib/require.js ??