[aerogear-dev] AeroGear.js without jQuery Discussion

Tue Mar 25 08:53:57 EDT 2014

On Tue, 25 Mar 2014 13:15:55 +0100
Lukáš Fryč <lukas.fryc at gmail.com> wrote:

> Side note: getting integration with jQuery{ajax,promises} right was one of
> the pain points when integrating with AeroGear.js / Angular (uses q.js, and
> custom http service).
> 
> 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)
> 

+1
I'd just add performance as additional criterion for polyfill selection.
Especially if we want to consider AGJS being used from Cordova apps.

> Wdyt?
> 
> 
> 
> On Tue, Mar 25, 2014 at 12:26 PM, Karel Piwko <kpiwko at redhat.com> wrote:
> 
> > Given number of supported browsers is quite low -
> > http://caniuse.com/promises, I
> > believe that polyfill will be needed even with version 2.0.
> >
> > On Mon, 24 Mar 2014 12:01:38 -0400
> > Lucas Holmquist <lholmqui at redhat.com> wrote:
> >
> > >
> > > On Mar 24, 2014, at 11:55 AM, Sebastien Blanc <scm.blanc at gmail.com>
> > wrote:
> > >
> > > >
> > > >
> > > >
> > > > On Mon, Mar 24, 2014 at 4:26 PM, Matthias Wessendorf <
> > matzew at apache.org>
> > > > wrote:
> > > >
> > > >
> > > >
> > > > On Mon, Mar 24, 2014 at 4:14 PM, Sebastien Blanc <scm.blanc at gmail.com>
> > > > wrote:
> > > >
> > > >
> > > >
> > > > On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist <lholmqui at redhat.com>
> > > > wrote:
> > > >
> > > > On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis <tolisemm at gmail.com>
> > > > wrote:
> > > >
> > > >> 2014-03-24 15:39 GMT+02:00 Matthias Wessendorf <matzew at apache.org>:
> > > >>
> > > >>
> > > >>
> > > >> On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist <lholmqui at redhat.com
> > >
> > > >> wrote:
> > > >>> I agree that it would be nice to implement AGJS-70 (Investigate
> > removing
> > > >>> jQuery requirement). Meanwhile, there is an open source project on
> > GitHub
> > > >>> that claims to offer a custom builder for jQuery in order to include
> > only
> > > >>> the modules needed [1] [2]. I haven't tried it yet but maybe we could
> > > >>> create a custom jQuery build which includes only the parts currently
> > > >>> needed in AeroGear. This would mean a smaller size of the jQuery
> > > >>> dependency.
> > > >>
> > > >> The AG lib depends on a few parts of jQuery, the biggest being
> > jQuery.Ajax
> > > >> and the promise implementation.
> > > >>
> > > >> i know we can make custom builds of jQuery pretty easily( building
> > from
> > > >> source ),  but i don't really want to bundle it within our lib.
> > > >>
> > > >> and i don't think with bower we can do this easily. although they did
> > just
> > > >> add a post install hook, so perhaps that could be something to look
> > at.
> > > >>
> > > >> Datamanager only uses the promise implementation of jQuery( and some
> > > >> random thing for the filter method,  which could probably be updated
> > ).
> > > >>
> > > >>
> > > >> Promises are starting to become available natively in browsers and
> > jQuery
> > > >> doesn't use the Promise/A+ spec,  so it could be harder to fallback
> > > >> without a shim of some kind
> > > >>
> > > >> Good to know. Thanks for providing this info.
> > > >>
> > > >>
> > > >> sounds reasonable to 'wait' on the promise side of things, and use
> > that
> > > >> bit in the datamanager
> > > >>
> > > >> +1
> > > >
> > > > there are other promise implementations that we could use, that are to
> > > > spec,  such as Q and RSVP,  here is the link to the HTML5 rocks article
> > > > http://www.html5rocks.com/en/tutorials/es6/promises/
> > > >
> > > > These last days I have been playing with the library When provided by
> > Cujo,
> > > > it's maybe also worth looking https://github.com/cujojs/when
> > > >
> > > > not sure I see value in using a different library as a temporary thing.
> > > > Once the API is part of the browser platform, the need for [yet
> > another js
> > > > lib] goes away. I know but I'm more concerned about  "Once the API is
> > part
> > > > of the browser platform" When will that happen and does it match with
> > our
> > > > roadmap ? Was also to offer a polyfill for older browser if we want to
> > keep
> > > > supporting them.
> > > >
> > > i will have to update the roadmap.
> > >
> > > 2.0 would be a nice time to "fully" switch,  but we can start
> > experimenting
> > > now and maybe for 1.5 can have some implemenation for data manager only.
> > >
> > > Current Chrome has Promise's enable by default and it looks like FireFox
> > > 29( next version ) will too.  Safari and IE are in dev i believe
> > >
> > > for fallback we can still make use of jQuery i think because of this
> > method
> > > here  "Promise.cast",  although the closest lib to the spec is RSVP(
> > maybe
> > > this could be the 2.0 fallback if we remove jQuery from the whole lib )
> > >
> > >
> > >
> > > >
> > > >
> > > >
> > > >
> > > >>
> > > >>
> > > >>
> > > >> while i don't really want to reinvent the wheel in terms of Ajax,  it
> > > >> might be interesting to take a look.
> > > >>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 at lists.jboss.org
> > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Matthias Wessendorf
> > > >>
> > > >> blog: http://matthiaswessendorf.wordpress.com/
> > > >> sessions: http://www.slideshare.net/mwessendorf
> > > >> twitter: http://twitter.com/mwessendorf
> > > >>
> > > >> _______________________________________________
> > > >> aerogear-dev mailing list
> > > >> aerogear-dev at lists.jboss.org
> > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >>
> > > >> _______________________________________________
> > > >> aerogear-dev mailing list
> > > >> aerogear-dev at lists.jboss.org
> > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > > >
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > > >
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > > >
> > > >
> > > > --
> > > > Matthias Wessendorf
> > > >
> > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > sessions: http://www.slideshare.net/mwessendorf
> > > > twitter: http://twitter.com/mwessendorf
> > > >
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >