[aerogear-dev] AeroGear.js without jQuery Discussion

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[aerogear-dev] AeroGear.js without jQuery Discussion

Luke Holmquist
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


while i don't really want to reinvent the wheel in terms of Ajax,  it might be interesting to take a look.  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







_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Miguel Lemos
Sorry, I don't understand why jQuery is needed to implement Ajax. We use Ajax to perform many tasks (both for mobile and desktop) and we NEVER use jQuery.


On Mon, Mar 24, 2014 at 1:03 PM, Lucas Holmquist <[hidden email]> 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


while i don't really want to reinvent the wheel in terms of Ajax,  it might be interesting to take a look.  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







_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Luke Holmquist

On Mar 24, 2014, at 9:25 AM, Miguel Lemos <[hidden email]> wrote:

Sorry, I don't understand why jQuery is needed to implement Ajax. We use Ajax to perform many tasks (both for mobile and desktop) and we NEVER use jQuery.

we are using the jQuery.Ajax library to our ajax calls,  make sense?



On Mon, Mar 24, 2014 at 1:03 PM, Lucas Holmquist <[hidden email]> 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


while i don't really want to reinvent the wheel in terms of Ajax,  it might be interesting to take a look.  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







_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Matthias Wessendorf
In reply to this post by Luke Holmquist



On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist <[hidden email]> 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

sounds reasonable to 'wait' on the promise side of things, and use that bit in the datamanager
 


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







_______________________________________________
aerogear-dev mailing list
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

tolis emmanouilidis
2014-03-24 15:39 GMT+02:00 Matthias Wessendorf <[hidden email]>:



On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist <[hidden email]> 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



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
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Luke Holmquist

On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis <[hidden email]> wrote:

2014-03-24 15:39 GMT+02:00 Matthias Wessendorf <[hidden email]>:



On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist <[hidden email]> 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  




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
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Sebastien Blanc
In reply to this post by Luke Holmquist



On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist <[hidden email]> 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


while i don't really want to reinvent the wheel in terms of Ajax,  it might be interesting to take a look.  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

Do you mean here relying on a "lighter" Ajax lib or just refactoring it using plain old XmlHttpRequest ? 








_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Sebastien Blanc
In reply to this post by Luke Holmquist



On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist <[hidden email]> wrote:

On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis <[hidden email]> wrote:

2014-03-24 15:39 GMT+02:00 Matthias Wessendorf <[hidden email]>:



On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist <[hidden email]> 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  

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
 




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
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Luke Holmquist
In reply to this post by Sebastien Blanc

On Mar 24, 2014, at 11:12 AM, Sebastien Blanc <[hidden email]> wrote:




On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist <[hidden email]> 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


while i don't really want to reinvent the wheel in terms of Ajax,  it might be interesting to take a look.  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

Do you mean here relying on a "lighter" Ajax lib or just refactoring it using plain old XmlHttpRequest ? 

we would have an internal AeroGear.Ajax( or something like that ) as our "lighter" ajax lib that used plain xmlhttprequests










_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Matthias Wessendorf



On Mon, Mar 24, 2014 at 4:15 PM, Lucas Holmquist <[hidden email]> wrote:

On Mar 24, 2014, at 11:12 AM, Sebastien Blanc <[hidden email]> wrote:




On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist <[hidden email]> 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


while i don't really want to reinvent the wheel in terms of Ajax,  it might be interesting to take a look.  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

Do you mean here relying on a "lighter" Ajax lib or just refactoring it using plain old XmlHttpRequest ? 

we would have an internal AeroGear.Ajax( or something like that ) as our "lighter" ajax lib that used plain xmlhttprequests


+1 on XHR usage - no other framework
 










_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Matthias Wessendorf
In reply to this post by Sebastien Blanc



On Mon, Mar 24, 2014 at 4:14 PM, Sebastien Blanc <[hidden email]> wrote:



On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist <[hidden email]> wrote:

On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis <[hidden email]> wrote:

2014-03-24 15:39 GMT+02:00 Matthias Wessendorf <[hidden email]>:



On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist <[hidden email]> 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  

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.

 
 




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
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Sebastien Blanc
In reply to this post by Matthias Wessendorf



On Mon, Mar 24, 2014 at 4:25 PM, Matthias Wessendorf <[hidden email]> wrote:



On Mon, Mar 24, 2014 at 4:15 PM, Lucas Holmquist <[hidden email]> wrote:

On Mar 24, 2014, at 11:12 AM, Sebastien Blanc <[hidden email]> wrote:




On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist <[hidden email]> 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


while i don't really want to reinvent the wheel in terms of Ajax,  it might be interesting to take a look.  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

Do you mean here relying on a "lighter" Ajax lib or just refactoring it using plain old XmlHttpRequest ? 

we would have an internal AeroGear.Ajax( or something like that ) as our "lighter" ajax lib that used plain xmlhttprequests


+1 on XHR usage - no other framework
+9001 \o/ 
 










_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Sebastien Blanc
In reply to this post by Matthias Wessendorf



On Mon, Mar 24, 2014 at 4:26 PM, Matthias Wessendorf <[hidden email]> wrote:



On Mon, Mar 24, 2014 at 4:14 PM, Sebastien Blanc <[hidden email]> wrote:



On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist <[hidden email]> wrote:

On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis <[hidden email]> wrote:

2014-03-24 15:39 GMT+02:00 Matthias Wessendorf <[hidden email]>:



On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist <[hidden email]> 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  

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.


 
 




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
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Luke Holmquist

On Mar 24, 2014, at 11:55 AM, Sebastien Blanc <[hidden email]> wrote:




On Mon, Mar 24, 2014 at 4:26 PM, Matthias Wessendorf <[hidden email]> wrote:



On Mon, Mar 24, 2014 at 4:14 PM, Sebastien Blanc <[hidden email]> wrote:



On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist <[hidden email]> wrote:

On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis <[hidden email]> wrote:

2014-03-24 15:39 GMT+02:00 Matthias Wessendorf <[hidden email]>:



On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist <[hidden email]> 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  

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
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Luke Holmquist

On Mar 24, 2014, at 12:01 PM, Lucas Holmquist <[hidden email]> wrote:


On Mar 24, 2014, at 11:55 AM, Sebastien Blanc <[hidden email]> wrote:




On Mon, Mar 24, 2014 at 4:26 PM, Matthias Wessendorf <[hidden email]> wrote:



On Mon, Mar 24, 2014 at 4:14 PM, Sebastien Blanc <[hidden email]> wrote:



On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist <[hidden email]> wrote:

On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis <[hidden email]> wrote:

2014-03-24 15:39 GMT+02:00 Matthias Wessendorf <[hidden email]>:



On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist <[hidden email]> 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  

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
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Sebastien Blanc
That's why I mentioned When.js  for an eventual 2.0 fallback lib 
"When.js is a rock solid, battle-tested Promises/A+ and when() implementation, including a complete ES6 Promise shim"


On Mon, Mar 24, 2014 at 5:07 PM, Lucas Holmquist <[hidden email]> wrote:

On Mar 24, 2014, at 12:01 PM, Lucas Holmquist <[hidden email]> wrote:


On Mar 24, 2014, at 11:55 AM, Sebastien Blanc <[hidden email]> wrote:




On Mon, Mar 24, 2014 at 4:26 PM, Matthias Wessendorf <[hidden email]> wrote:



On Mon, Mar 24, 2014 at 4:14 PM, Sebastien Blanc <[hidden email]> wrote:



On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist <[hidden email]> wrote:

On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis <[hidden email]> wrote:

2014-03-24 15:39 GMT+02:00 Matthias Wessendorf <[hidden email]>:



On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist <[hidden email]> 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  

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
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Luke Holmquist

On Mar 24, 2014, at 12:11 PM, Sebastien Blanc <[hidden email]> wrote:

That's why I mentioned When.js  for an eventual 2.0 fallback lib 
"When.js is a rock solid, battle-tested Promises/A+ and when() implementation, including a complete ES6 Promise shim"

if we do it right,  a user could use any promise lib that is to spec



On Mon, Mar 24, 2014 at 5:07 PM, Lucas Holmquist <[hidden email]> wrote:

On Mar 24, 2014, at 12:01 PM, Lucas Holmquist <[hidden email]> wrote:


On Mar 24, 2014, at 11:55 AM, Sebastien Blanc <[hidden email]> wrote:




On Mon, Mar 24, 2014 at 4:26 PM, Matthias Wessendorf <[hidden email]> wrote:



On Mon, Mar 24, 2014 at 4:14 PM, Sebastien Blanc <[hidden email]> wrote:



On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist <[hidden email]> wrote:

On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis <[hidden email]> wrote:

2014-03-24 15:39 GMT+02:00 Matthias Wessendorf <[hidden email]>:



On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist <[hidden email]> 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  

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
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Miguel Lemos
Meanwhile: there are several possibilities to build a customized (smaller) jQuery library.
For instance:


No dia 24/03/2014, às 17:11, Lucas Holmquist <[hidden email]> escreveu:


On Mar 24, 2014, at 12:11 PM, Sebastien Blanc <[hidden email]> wrote:

That's why I mentioned When.js  for an eventual 2.0 fallback lib 
"When.js is a rock solid, battle-tested Promises/A+ and when() implementation, including a complete ES6 Promise shim"

if we do it right,  a user could use any promise lib that is to spec



On Mon, Mar 24, 2014 at 5:07 PM, Lucas Holmquist <[hidden email]> wrote:

On Mar 24, 2014, at 12:01 PM, Lucas Holmquist <[hidden email]> wrote:


On Mar 24, 2014, at 11:55 AM, Sebastien Blanc <[hidden email]> wrote:




On Mon, Mar 24, 2014 at 4:26 PM, Matthias Wessendorf <[hidden email]> wrote:



On Mon, Mar 24, 2014 at 4:14 PM, Sebastien Blanc <[hidden email]> wrote:



On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist <[hidden email]> wrote:

On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis <[hidden email]> wrote:

2014-03-24 15:39 GMT+02:00 Matthias Wessendorf <[hidden email]>:



On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist <[hidden email]> 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  

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
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Bruno Oliveira
In reply to this post by Luke Holmquist
That would be a big win

> On Mar 24, 2014, at 2:11 PM, Lucas Holmquist <[hidden email]> wrote:
>
> if we do it right,  a user could use any promise lib that is to spec
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Miguel Lemos
Assuming that are really needed (?) external libraries to execute asynchronous calls, here is a comparaison. And as you can see jQuery performs not very well...



Enviado do meu iPad

No dia 24/03/2014, às 21:17, Bruno Oliveira <[hidden email]> escreveu:

That would be a big win

On Mar 24, 2014, at 2:11 PM, Lucas Holmquist <[hidden email]> wrote:

if we do it right,  a user could use any promise lib that is to spec
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
12