[aerogear-dev] AeroGear.js without jQuery Discussion

Lucas Holmquist lholmqui at redhat.com
Wed Apr 2 08:22:25 EDT 2014 

On Apr 2, 2014, at 7:07 AM, Lukáš Fryč <lukas.fryc at gmail.com> wrote:

> 
> 
> 
> On Wed, Apr 2, 2014 at 2:08 AM, Lucas Holmquist <lholmqui at redhat.com> wrote:
> 
> On Apr 1, 2014, at 5:05 PM, Lukáš Fryč <lukas.fryc at gmail.com> wrote:
> 
>> I'm all for using promises that actually make sense,
>> but have you considered consistency?
>> 
>> Are you suggesting some modules will return jQuery.Deferred while others will use ES6 promises?
> 
> i re read what i wrote and i think i wrote it very confusingly(?), not sure that is a word,  but i'm going with it
> 
> I would like to start with the UnifiedPushClient and remove the jQuery dependency from that.  It would then return an ES6 promise instead, or you can still use callbacks.
> 
> Good point, jQuery fans who will start to use ES6 promises won't receive just few additional parameters, but otherwise they can keep using a then(success, error) syntax.
>  
> 
> i think this might be ok for a next release, 1.5.0, since the api is labeled experimental.
> 
> 
> For datamanager,  2 out of the 4 adapters are labeled experimental, so we would not change the promises return type until 2.0
> 
> what i previously wrote sounded like i wanted to change 2 data manager adapters while keeping the other 2 the same.
> 
> Yea, that's what I heard, thanks for explanation. :-)
> 
> 
> 
> 
>> 
>> I would vote for all or nothing. ;-)
>> 
>> 
>> What about allow a developer to override what promise will be returned?
>> We can pass all promises through singleton (that can be overwritten/plugged-in by the developer),
>> and that will decide what promise to return.
> 
> This could be interesting,  but i would like to keep things simple first
> 
> +1 for simplicity
> 
> 
> So just to re-iterate, the plan is to keep stable 1.x APIs as they are,
> but in new APIs, leverage promises and offer people a polyfill.
> 
> In 2.x, we can fully embrace ES6 promises.

correct

>  
> 
>> 
>> In 1.x it can return jQuery.Deferred by default (but can be rewritten to Promise).
>> In 2.x it can return Promise (as in ES6) by default (but can be rewritten to jQuery.Deferred).
>> 
>> 
>> 
>> 
>> On Tue, Apr 1, 2014 at 3:36 PM, Sebastien Blanc <scm.blanc at gmail.com> wrote:
>> 
>> 
>> 
>> On Tue, Apr 1, 2014 at 3:17 PM, Lucas Holmquist <lholmqui at redhat.com> wrote:
>> in the canary branch i started looking at removing jQuery from the UnifiedPush client code,  since it only uses jQuery.Ajax.  
>> 
>> https://github.com/aerogear/aerogear-js/tree/canary
>> 
>> That's really cool and I will probably use this in my experimental FirefoxOS support for the Cordova Push Plugin 
>> 
>> i was thinking this would be a 2.0 thing,  but for this particular module/adapter/whatevs, i think we can update it before that since we marked  it "experimental"
>> 
>> in datamanager we have the IndexedDB and WebSQL adapters marked as experimental,  so we could do those, but since the other 2 adapters are not, we should probably wait.
>> 
>> Just want to see what the team thought about that, before i started to go cray-cray
>> 
>> 
>> -Luke
>> 
>> 
>> On Mar 25, 2014, at 8:58 AM, Lucas Holmquist <lholmqui at redhat.com> wrote:
>> 
>>> 
>>> On Mar 25, 2014, at 8:15 AM, Lukáš Fryč <lukas.fryc at gmail.com> wrote:
>>> 
>>>> Side note: getting integration with jQuery{ajax,promises} right was one of the pain points when integrating with AeroGear.js / Angular (uses q.js, and custom http service).
>>>> 
>>> i know they include their "own" version of jQuery
>>> 
>>>> We must be sure whatever we choose is compatible with frameworks out there (at least it should not hard-nut to make it work). In terms of promises implementation. In the end people may even end up using 2-3 promise approaches in one project that makes code pretty disgusting.
>>>> 
>>>> So:
>>>> 
>>>> +1 getting rid of jQuery.ajax
>>>> +1 getting rid of jQuery promises (they are just wrong anyway ;-)
>>>> 
>>>> 
>>>> Btw in terms of polyfilling, I would suggest:
>>>> 
>>>> 1) use whatever standard is as long as supported by majority of mainstream browsers
>>>> 
>>>> 2) use whatever standard will be and compile polyfill into aerogear.js (as long as it's not too bloated; not necessary for bower users)
>>>> 
>>> the polyfill i was thinking about is here https://github.com/jakearchibald/es6-promise
>>> 
>>> it is just the spec and 2kb gzipped, which is nice
>>> 
>>> and i think this could be an external( compiled in ) dep of the library
>>> 
>>> 
>>>> Wdyt?
>>>> 
>>>> 
>>>> 
>>>> On Tue, Mar 25, 2014 at 12:26 PM, Karel Piwko <kpiwko at redhat.com> wrote:
>>>> Given number of supported browsers is quite low - http://caniuse.com/promises, I
>>>> believe that polyfill will be needed even with version 2.0.
>>>> 
>>>> On Mon, 24 Mar 2014 12:01:38 -0400
>>>> Lucas Holmquist <lholmqui at redhat.com> wrote:
>>>> 
>>>> >
>>>> > On Mar 24, 2014, at 11:55 AM, Sebastien Blanc <scm.blanc at gmail.com> wrote:
>>>> >
>>>> > >
>>>> > >
>>>> > >
>>>> > > On Mon, Mar 24, 2014 at 4:26 PM, Matthias Wessendorf <matzew at apache.org>
>>>> > > wrote:
>>>> > >
>>>> > >
>>>> > >
>>>> > > On Mon, Mar 24, 2014 at 4:14 PM, Sebastien Blanc <scm.blanc at gmail.com>
>>>> > > wrote:
>>>> > >
>>>> > >
>>>> > >
>>>> > > On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist <lholmqui at redhat.com>
>>>> > > wrote:
>>>> > >
>>>> > > On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis <tolisemm at gmail.com>
>>>> > > wrote:
>>>> > >
>>>> > >> 2014-03-24 15:39 GMT+02:00 Matthias Wessendorf <matzew at apache.org>:
>>>> > >>
>>>> > >>
>>>> > >>
>>>> > >> On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist <lholmqui at redhat.com>
>>>> > >> wrote:
>>>> > >>> I agree that it would be nice to implement AGJS-70 (Investigate removing
>>>> > >>> jQuery requirement). Meanwhile, there is an open source project on GitHub
>>>> > >>> that claims to offer a custom builder for jQuery in order to include only
>>>> > >>> the modules needed [1] [2]. I haven't tried it yet but maybe we could
>>>> > >>> create a custom jQuery build which includes only the parts currently
>>>> > >>> needed in AeroGear. This would mean a smaller size of the jQuery
>>>> > >>> dependency.
>>>> > >>
>>>> > >> The AG lib depends on a few parts of jQuery, the biggest being jQuery.Ajax
>>>> > >> and the promise implementation.
>>>> > >>
>>>> > >> i know we can make custom builds of jQuery pretty easily( building from
>>>> > >> source ),  but i don't really want to bundle it within our lib.
>>>> > >>
>>>> > >> and i don't think with bower we can do this easily. although they did just
>>>> > >> add a post install hook, so perhaps that could be something to look at.
>>>> > >>
>>>> > >> Datamanager only uses the promise implementation of jQuery( and some
>>>> > >> random thing for the filter method,  which could probably be updated ).
>>>> > >>
>>>> > >>
>>>> > >> Promises are starting to become available natively in browsers and jQuery
>>>> > >> doesn't use the Promise/A+ spec,  so it could be harder to fallback
>>>> > >> without a shim of some kind
>>>> > >>
>>>> > >> Good to know. Thanks for providing this info.
>>>> > >>
>>>> > >>
>>>> > >> sounds reasonable to 'wait' on the promise side of things, and use that
>>>> > >> bit in the datamanager
>>>> > >>
>>>> > >> +1
>>>> > >
>>>> > > there are other promise implementations that we could use, that are to
>>>> > > spec,  such as Q and RSVP,  here is the link to the HTML5 rocks article
>>>> > > http://www.html5rocks.com/en/tutorials/es6/promises/
>>>> > >
>>>> > > These last days I have been playing with the library When provided by Cujo,
>>>> > > it's maybe also worth looking https://github.com/cujojs/when
>>>> > >
>>>> > > not sure I see value in using a different library as a temporary thing.
>>>> > > Once the API is part of the browser platform, the need for [yet another js
>>>> > > lib] goes away. I know but I'm more concerned about  "Once the API is part
>>>> > > of the browser platform" When will that happen and does it match with our
>>>> > > roadmap ? Was also to offer a polyfill for older browser if we want to keep
>>>> > > supporting them.
>>>> > >
>>>> > i will have to update the roadmap.
>>>> >
>>>> > 2.0 would be a nice time to "fully" switch,  but we can start experimenting
>>>> > now and maybe for 1.5 can have some implemenation for data manager only.
>>>> >
>>>> > Current Chrome has Promise's enable by default and it looks like FireFox
>>>> > 29( next version ) will too.  Safari and IE are in dev i believe
>>>> >
>>>> > for fallback we can still make use of jQuery i think because of this method
>>>> > here  "Promise.cast",  although the closest lib to the spec is RSVP( maybe
>>>> > this could be the 2.0 fallback if we remove jQuery from the whole lib )
>>>> >
>>>> >
>>>> >
>>>> > >
>>>> > >
>>>> > >
>>>> > >
>>>> > >>
>>>> > >>
>>>> > >>
>>>> > >> while i don't really want to reinvent the wheel in terms of Ajax,  it
>>>> > >> might be interesting to take a look.
>>>> > >>
>>>> > >> Yeah, IMO worth to look there, for reducing dependencies
>>>> > >>
>>>> > >> -M
>>>> > >>
>>>> > >>
>>>> > >>
>>>> > >>
>>>> > >>  I think in a previous ML thread about what 2.0 looked like,  that
>>>> > >> Pipeline would maybe just be a JSON only thing, with exception for
>>>> > >> multipart
>>>> > >>
>>>> > >>
>>>> > >>
>>>> > >> @Lucas Thanks for making things clear
>>>> > >>
>>>> > >>
>>>> > >>
>>>> > >>
>>>> > >>
>>>> > >>
>>>> > >> _______________________________________________
>>>> > >> aerogear-dev mailing list
>>>> > >> aerogear-dev at lists.jboss.org
>>>> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>> > >>
>>>> > >>
>>>> > >>
>>>> > >> --
>>>> > >> Matthias Wessendorf
>>>> > >>
>>>> > >> blog: http://matthiaswessendorf.wordpress.com/
>>>> > >> sessions: http://www.slideshare.net/mwessendorf
>>>> > >> twitter: http://twitter.com/mwessendorf
>>>> > >>
>>>> > >> _______________________________________________
>>>> > >> aerogear-dev mailing list
>>>> > >> aerogear-dev at lists.jboss.org
>>>> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>> > >>
>>>> > >> _______________________________________________
>>>> > >> aerogear-dev mailing list
>>>> > >> aerogear-dev at lists.jboss.org
>>>> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>> > >
>>>> > >
>>>> > > _______________________________________________
>>>> > > aerogear-dev mailing list
>>>> > > aerogear-dev at lists.jboss.org
>>>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>> > >
>>>> > >
>>>> > > _______________________________________________
>>>> > > aerogear-dev mailing list
>>>> > > aerogear-dev at lists.jboss.org
>>>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>> > >
>>>> > >
>>>> > >
>>>> > > --
>>>> > > Matthias Wessendorf
>>>> > >
>>>> > > blog: http://matthiaswessendorf.wordpress.com/
>>>> > > sessions: http://www.slideshare.net/mwessendorf
>>>> > > twitter: http://twitter.com/mwessendorf
>>>> > >
>>>> > > _______________________________________________
>>>> > > aerogear-dev mailing list
>>>> > > aerogear-dev at lists.jboss.org
>>>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>> > >
>>>> > > _______________________________________________
>>>> > > aerogear-dev mailing list
>>>> > > aerogear-dev at lists.jboss.org
>>>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>> >
>>>> 
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>> 
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> 
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> 
>> 
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> 
>> 
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> 
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140402/8f545338/attachment-0001.html

More information about the aerogear-dev mailing list