[aerogear-dev] AeroGear.js without jQuery Discussion

Sebastien Blanc scm.blanc at gmail.com
Tue Apr 1 09:36:46 EDT 2014 

On Tue, Apr 1, 2014 at 3:17 PM, Lucas Holmquist <lholmqui at redhat.com> 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 at redhat.com> wrote:
>
>
> On Mar 25, 2014, at 8:15 AM, 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).
>
> 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 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.
>> > >>
>> > >> 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
>>
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/f2aa2169/attachment.html

More information about the aerogear-dev mailing list