Re: Single asynchronous primitive vs. several.

[Rob Wormald]

Sent from my iPhone

On May 7, 2015, at 4:00 PM, Jeff Cross <middl...@gmail.com> wrote:

I understand and appreciate that Benjamin's original motivation was to push for generally considering mixing primitives rather than standardizing on one. Good perspectives and ideas have been presented by all. If you have specific APIs within Angular core in which you'd like to discuss the use of observables or other primitives, feel free to open an issue for discussion at angular/angular, as this group is only a tiny subset of the people involved in design decisions in Angular.

Regarding Http, it's a pretty simple library, and just because we're building an official one in core, doesn't mean anyone in the community (including people in this thread) can't create their own alternative implementation. It has no technical preference or advantage over any other third-party http library, just some advertising benefits of being in our official documentation.

I'm locking this topic. I think everything to be said has been said 10 times :). I now want to never use a Promise or Observable again, back to callbacks!

On Thursday, May 7, 2015 at 3:27:16 PM UTC-7, wardb wrote:

+100 to Ben G's reasoning.

I realize that "+100" doesn't add substance. It *does* mean he has company.

I keep hearing many of you say that promises are inadequate most of the time. That flies in the face of a huge number of very successful deployments out there. 

It is blindingly obvious just looking at the body of existing apps in the wild that a single, cold response - a promise response - is exactly what we need most of the time from our client/server HTTP interactions. "Get me the Customer with Id = 42".  That is an unambiguous request for a single response. Once I have it, I have it. I can pass that resolved promise along and its value will be immediately available. I don't risk another turn or an unwanted trip to the server.

This is the bread and butter of application HTTP requests.  I don't see this changing very much for the foreseeable future.  I DO see more push interactions in the near future ... and these are perfect candidates for observables. But HTTP? Seriously?

The retry/cancellation critique is a red herring ... as Ben G. explains. For the record, retry and cancellation with promises is something we've long known how to do  ... when we've needed them. The real problem has been knowing when, why, and what to do when cancelling/retrying. Those are much more difficult issues ... issues that *observables do not solve any better than promises*. What is the program supposed to do when the user cancels? Aborting is not always the right answer. Why bother retrying if the connection is broken? How often do you retry? Do you progressively delay the next retry? These are not questions whose answers turn on whether you use promises or observables.

Promises are far easier to explain than observables .... straight up. If you took people who knew neither, you could be sure they'd learn promises before they got anywhere with observables. This "experiment" has been tried many times already in the real world over the last few years. We know that promises are widely understood today ... especially within the Ng community ... whereas Rx has had pathetic traction.

Let's also get real about Angular's ability to change the world. Angular played a very small (and belated) role in teaching promises.  Angular v.2 may well encourage learning of observables and Rx principles. But we should practice some humility. Let's not exaggerate the Angular Elite's ability to overcome the resistance to Rx when so many others have failed.

Most importantly ... we have to bring the Ng v.1 community with us. ***That community is already pissed off about Ng 2***. We should not blithely add to the discontent by forcing yet another difficult paradigm down their throats.

Finally, I want to reiterate that ... **like Ben G ... I am in favor of observables in Ng. 2.0**.  I am a fan!  I love observables!  Can we just stipulate that?

My argument is that we can't force observables on the Ng community. They're is no valid reason to do so. And they will hate us for it. We can and should offer both.

--
You received this message because you are subscribed to the Google Groups "angular-data-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angular-data-d...@googlegroups.com.
To post to this group, send email to angular-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/angular-data-dev/c2d0656c-2e88-47c6-bcfd-c683f466c2c5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jeff Cross]

Haha, that's the spirit!

On Thursday, May 7, 2015 at 4:39:54 PM UTC-7, Rob Wormald wrote:

Sent from my iPhone

To unsubscribe from this group and stop receiving emails from it, send an email to angular-data-dev+unsubscribe@googlegroups.com.
To post to this group, send email to angular-data-dev@googlegroups.com.

[Rob Wormald]

One teeny tiny closing suggestion. Having really dug into Observables recently (I'll do another post with a super neato use case I'm working on shortly) - I'm more or less okay with either. I realized that the thing that really bugs me is the *name*, Http.

I reckon 99% of angular 1.x devs trying 2.0 for the first time are going to inject Http, expect it to work like $http, treat it like a promise, and be utterly confused. 

Perhaps a change in name to make it clear it's a change in behavior? It's a bit of armchair psychology, but "new" is better than "breaking change". 

We can have the inevitable naming argument in another thread. 

Rob

Sent from my iPhone

To unsubscribe from this group and stop receiving emails from it, send an email to angular-data-d...@googlegroups.com.
To post to this group, send email to angular-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/angular-data-dev/cd2f9a7d-7d2b-45ed-b7cb-cbf5c2bf8836%40googlegroups.com.