incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Viras <>
Subject Re: Unified phonegap javascript layer incorperating modules / plugins
Date Sat, 19 Nov 2011 11:09:20 GMT
I'm really looking forward to this. I've done some work on a single
javascript for cross-platform and just some platform specific
implementations (like the PG.exec function).

However I would avoid sticking to a syntax of a popular framework. E.g.
I'm a fan of jquery and I'm using for my app with great
success, however if you now force me to stick to a commonJS like syntax
for callback it will be quite confusing.

I would try to stick to "standard" (whatever that is) javascript calls
like callback does right now - this doesn't set any preferences for any
additonal JS frameworks which might be used together with callback.

In addition my vote goes to handling as much of the API logic as
possible on the JS side (of course platform independence is still top

I did something like that for my rewrite of the callback-qt code. The
geolocation code contains the whole timeout code on the javascript side,
which reduced the native code to a minimum and will make porting
callback to new platforms way more easy.

I'm using the same base javascript for both my versions of phonegap-qt &

Just my thoughts....

Am 19.11.2011 06:35, schrieb Brian LeRoux:
> As a quick update, I pinged brendan and harmony separates the
> definition of modules (into a commonjs inspired syntax) and the
> loading of modules into a new api called module loader api. So,
> basically, these things are not mutually exclusive.
> Which is actually how Gord did things ... perhaps our loader can be
> AMD satisfying the technical requirements outlined here and the
> definition can be in the CommonJS style. For those doing browser dev
> or that want worse performance they can use the Loader. For those
> building phonegap apps (into a phone) the compiler does the job.
> There are a bunch of google-able articles about how to do this (really
> good one from sitepen).
> On Sat, Nov 19, 2011 at 6:28 AM, Brian LeRoux <> wrote:
>>>> - better performance
>>>> - better aesthetics
>>>> - closer to the future
>>> "closer to the future" is factually incorrect. The other two are unqualified
>>> assertions.
>> Wow, nothing like nuanced debate on semantics pretending to be
>> academic. You say I don't qualify my statements but provide no
>> evidence of your own. Look forward to seeing the code. I agree its
>> *possible* to write something that has less footprint, and said as
>> much, but the semantics of AMD are read/writ in a more involved
>> fashion for the end developer than a simple exports object.
>> As to the Harmony compat, that was from a brendan eich talk (that we
>> both attended btw). It was a goal which maybe changed but thats not
>> the point. The syntax for CommonJS is closer than the ceremony we see
>> in AMD which was why I said there will be changes. I suppose that
>> wasn't clear enough.
>> Anyhow, none of this matters until we see the proposal in code form.
>> Right now we're debating aesthetics and developer ergonomics which
>> always sounds abjectly religious.

GOFG - Get On Fat Guy - powered by PhoneGap

View raw message