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

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