Re: [aerogear-dev] AeroGear.js without jQuery Discussion

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