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

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