Sorry, I don't understand why jQuery is needed to implement Ajax. We use Ajax to perform many tasks (both for mobile and desktop) and we NEVER use jQuery.

On Mon, Mar 24, 2014 at 1:03 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; 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 while i don't really want to reinvent the wheel in terms of Ajax, it might be interesting to take a look. 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;wrote: > I agree that it would be nice to implement AGJS-70<https://issues.jboss.org/browse/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 >

sounds reasonable to 'wait' on the promise side of things, and use that bit in the datamanager

> > 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 > > >

> > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis <tolisemm(a)gmail.com&gt; wrote: 2014-03-24 15:39 GMT+02:00 Matthias Wessendorf <matzew(a)apache.org&gt;: > > > > On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;wrote: > >> I agree that it would be nice to implement AGJS-70<https://issues.jboss.org/browse/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/

>> >> 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(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Mon, Mar 24, 2014 at 4:14 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: > > > > On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;wrote: > >> >> On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis <tolisemm(a)gmail.com&gt; >> wrote: >> >> 2014-03-24 15:39 GMT+02:00 Matthias Wessendorf <matzew(a)apache.org&gt;: >> >>> >>> >>> >>> On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;wrote: >>> >>>> I agree that it would be nice to implement AGJS-70<https://issues.jboss.org/browse/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.

> > >> >> >> >>>> >>>> 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(a)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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Mar 24, 2014, at 11:55 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > > > > On Mon, Mar 24, 2014 at 4:26 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > > On Mon, Mar 24, 2014 at 4:14 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > > > > On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > > On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis <tolisemm(a)gmail.com&gt; wrote: > >> 2014-03-24 15:39 GMT+02:00 Matthias Wessendorf <matzew(a)apache.org&gt;: >> >> >> >> On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; 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(a)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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

That's why I mentioned When.js for an eventual 2.0 fallback lib "When.js is a rock solid, battle-tested Promises/A+ and when() implementation, including a complete ES6 Promise shim"

On Mon, Mar 24, 2014 at 5:07 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: On Mar 24, 2014, at 12:01 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > > On Mar 24, 2014, at 11:55 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > >> >> >> >> On Mon, Mar 24, 2014 at 4:26 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> >> >> >> On Mon, Mar 24, 2014 at 4:14 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >> >> >> >> On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: >> >> On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis <tolisemm(a)gmail.com&gt; wrote: >> >>> 2014-03-24 15:39 GMT+02:00 Matthias Wessendorf <matzew(a)apache.org&gt;: >>> >>> >>> >>> On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; 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", please strike this comment from the record, i'm an idiot :) > 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(a)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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Meanwhile: there are several possibilities to build a customized (smaller) jQuery library. For instance: http://projects.jga.me/jquery-builder/

Enviado do meu iPad No dia 24/03/2014, às 17:11, Lucas Holmquist <lholmqui(a)redhat.com&gt; escreveu: > > On Mar 24, 2014, at 12:11 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > >> That's why I mentioned When.js for an eventual 2.0 fallback lib >> "When.js is a rock solid, battle-tested Promises/A+ and when() implementation, including a complete ES6 Promise shim" > > if we do it right, a user could use any promise lib that is to spec > >> >> >> On Mon, Mar 24, 2014 at 5:07 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: >> >> On Mar 24, 2014, at 12:01 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: >> >>> >>> On Mar 24, 2014, at 11:55 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>> >>>> >>>> >>>> >>>> On Mon, Mar 24, 2014 at 4:26 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>>> >>>> >>>> >>>> On Mon, Mar 24, 2014 at 4:14 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>>> >>>> >>>> >>>> On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: >>>> >>>> On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis <tolisemm(a)gmail.com&gt; wrote: >>>> >>>>> 2014-03-24 15:39 GMT+02:00 Matthias Wessendorf <matzew(a)apache.org&gt;: >>>>> >>>>> >>>>> >>>>> On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; 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", >> >> please strike this comment from the record, i'm an idiot :) >> >>> 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(a)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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Mar 24, 2014, at 2:11 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: if we do it right, a user could use any promise lib that is to spec

On Mar 24, 2014, at 11:55 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > > > > On Mon, Mar 24, 2014 at 4:26 PM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > > > On Mon, Mar 24, 2014 at 4:14 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; > wrote: > > > > On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; > wrote: > > On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis <tolisemm(a)gmail.com&gt; > wrote: > >> 2014-03-24 15:39 GMT+02:00 Matthias Wessendorf <matzew(a)apache.org&gt;: >> >> >> >> On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; >> 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(a)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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev

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). 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)

Wdyt? On Tue, Mar 25, 2014 at 12:26 PM, Karel Piwko <kpiwko(a)redhat.com&gt; 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(a)redhat.com&gt; wrote: > > > > > On Mar 24, 2014, at 11:55 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; > wrote: > > > > > > > > > > > > > > On Mon, Mar 24, 2014 at 4:26 PM, Matthias Wessendorf < > matzew(a)apache.org&gt; > > > wrote: > > > > > > > > > > > > On Mon, Mar 24, 2014 at 4:14 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; > > > wrote: > > > > > > > > > > > > On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; > > > wrote: > > > > > > On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis <tolisemm(a)gmail.com&gt; > > > wrote: > > > > > >> 2014-03-24 15:39 GMT+02:00 Matthias Wessendorf <matzew(a)apache.org&gt;: > > >> > > >> > > >> > > >> On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist <lholmqui(a)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. > > >>http://postimg.org/image/6mbqdbvkv/ > > >> 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(a)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(a)lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >> > > >> _______________________________________________ > > >> aerogear-dev mailing list > > >> aerogear-dev(a)lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev(a)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(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev >

On Mar 25, 2014, at 8:15 AM, Lukáš Fryč <lukas.fryc(a)gmail.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; wrote: > > > > > On Mar 24, 2014, at 11:55 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > > > > > > > > > > > > > > On Mon, Mar 24, 2014 at 4:26 PM, Matthias Wessendorf <matzew(a)apache.org&gt; > > > wrote: > > > > > > > > > > > > On Mon, Mar 24, 2014 at 4:14 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; > > > wrote: > > > > > > > > > > > > On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; > > > wrote: > > > > > > On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis <tolisemm(a)gmail.com&gt; > > > wrote: > > > > > >> 2014-03-24 15:39 GMT+02:00 Matthias Wessendorf <matzew(a)apache.org&gt;: > > >> > > >> > > >> > > >> On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; > > >> 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(a)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(a)lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >> > > >> _______________________________________________ > > >> aerogear-dev mailing list > > >> aerogear-dev(a)lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev(a)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(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Apr 1, 2014, at 9:17 AM, Lucas Holmquist <lholmqui(a)redhat.com&gt; 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 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" it's not just an internal change, since it returns a jQuery Defered object, so the return value would be different

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(a)redhat.com&gt; wrote: On Mar 25, 2014, at 8:15 AM, Lukáš Fryč <lukas.fryc(a)gmail.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; wrote: > > > > > On Mar 24, 2014, at 11:55 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; > wrote: > > > > > > > > > > > > > > On Mon, Mar 24, 2014 at 4:26 PM, Matthias Wessendorf < > matzew(a)apache.org&gt; > > > wrote: > > > > > > > > > > > > On Mon, Mar 24, 2014 at 4:14 PM, Sebastien Blanc <scm.blanc(a)gmail.com > > > > > wrote: > > > > > > > > > > > > On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist <lholmqui(a)redhat.com > > > > > wrote: > > > > > > On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis <tolisemm(a)gmail.com > > > > > wrote: > > > > > >> 2014-03-24 15:39 GMT+02:00 Matthias Wessendorf <matzew(a)apache.org&gt;: > > >> > > >> > > >> > > >> On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist < > lholmqui(a)redhat.com&gt; > > >> 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(a)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(a)lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >> > > >> _______________________________________________ > > >> aerogear-dev mailing list > > >> aerogear-dev(a)lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev(a)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(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Tue, Apr 1, 2014 at 3:17 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;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(a)redhat.com&gt; wrote: > > > On Mar 25, 2014, at 8:15 AM, Lukáš Fryč <lukas.fryc(a)gmail.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; wrote: >> >> > >> > On Mar 24, 2014, at 11:55 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >> wrote: >> > >> > > >> > > >> > > >> > > On Mon, Mar 24, 2014 at 4:26 PM, Matthias Wessendorf < >> matzew(a)apache.org&gt; >> > > wrote: >> > > >> > > >> > > >> > > On Mon, Mar 24, 2014 at 4:14 PM, Sebastien Blanc < >> scm.blanc(a)gmail.com&gt; >> > > wrote: >> > > >> > > >> > > >> > > On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist < >> lholmqui(a)redhat.com&gt; >> > > wrote: >> > > >> > > On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis < >> tolisemm(a)gmail.com&gt; >> > > wrote: >> > > >> > >> 2014-03-24 15:39 GMT+02:00 Matthias Wessendorf <matzew(a)apache.org&gt;: >> > >> >> > >> >> > >> >> > >> On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist < >> lholmqui(a)redhat.com&gt; >> > >> 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(a)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(a)lists.jboss.org >> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> >> > >> _______________________________________________ >> > >> aerogear-dev mailing list >> > >> aerogear-dev(a)lists.jboss.org >> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > >> > > >> > > _______________________________________________ >> > > aerogear-dev mailing list >> > > aerogear-dev(a)lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > >> > > >> > > _______________________________________________ >> > > aerogear-dev mailing list >> > > aerogear-dev(a)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(a)lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > >> > > _______________________________________________ >> > > aerogear-dev mailing list >> > > aerogear-dev(a)lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Apr 1, 2014, at 5:05 PM, Lukáš Fryč <lukas.fryc(a)gmail.com&gt; 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.

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.

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

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(a)gmail.com&gt;wrote: > > > > On Tue, Apr 1, 2014 at 3:17 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;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(a)redhat.com&gt; >> wrote: >> >> >> On Mar 25, 2014, at 8:15 AM, Lukáš Fryč <lukas.fryc(a)gmail.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; wrote: >>> >>> > >>> > On Mar 24, 2014, at 11:55 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>> wrote: >>> > >>> > > >>> > > >>> > > >>> > > On Mon, Mar 24, 2014 at 4:26 PM, Matthias Wessendorf < >>> matzew(a)apache.org&gt; >>> > > wrote: >>> > > >>> > > >>> > > >>> > > On Mon, Mar 24, 2014 at 4:14 PM, Sebastien Blanc < >>> scm.blanc(a)gmail.com&gt; >>> > > wrote: >>> > > >>> > > >>> > > >>> > > On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist < >>> lholmqui(a)redhat.com&gt; >>> > > wrote: >>> > > >>> > > On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis < >>> tolisemm(a)gmail.com&gt; >>> > > wrote: >>> > > >>> > >> 2014-03-24 15:39 GMT+02:00 Matthias Wessendorf <matzew(a)apache.org >>> >: >>> > >> >>> > >> >>> > >> >>> > >> On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist < >>> lholmqui(a)redhat.com&gt; >>> > >> 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(a)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(a)lists.jboss.org >>> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > >> >>> > >> _______________________________________________ >>> > >> aerogear-dev mailing list >>> > >> aerogear-dev(a)lists.jboss.org >>> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > > >>> > > >>> > > _______________________________________________ >>> > > aerogear-dev mailing list >>> > > aerogear-dev(a)lists.jboss.org >>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > > >>> > > >>> > > _______________________________________________ >>> > > aerogear-dev mailing list >>> > > aerogear-dev(a)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(a)lists.jboss.org >>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > > >>> > > _______________________________________________ >>> > > aerogear-dev mailing list >>> > > aerogear-dev(a)lists.jboss.org >>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

I agree that it would be nice to implement AGJS-70<https://issues.jboss.org/browse/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 while i don't really want to reinvent the wheel in terms of Ajax, it might be interesting to take a look. 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

_______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Mar 24, 2014, at 11:12 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;wrote: > I agree that it would be nice to implement AGJS-70<https://issues.jboss.org/browse/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 > > > while i don't really want to reinvent the wheel in terms of Ajax, it > might be interesting to take a look. 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 > Do you mean here relying on a "lighter" Ajax lib or just refactoring it using plain old XmlHttpRequest ? we would have an internal AeroGear.Ajax( or something like that ) as our "lighter" ajax lib that used plain xmlhttprequests

> > > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev