Echo JS 0.11.0


Neonsquare 292 days ago. link 3 points
I agree to city41 is basically wishing promises were observables. It is on purpose and following an agenda though. Its clear that observables allow for use patterns that cannot or only cumbersome modelled using promises. Observables are a useful tool for certain use cases.

What I do NOT like is the tone of the article which tries to shift the reasoning about promises into something distasteful. Calling them "not neutral" which is meant as the opposite to "opinionated" and meant in a negative way. While the arguments seem to be constructed in a way to make observables stand out as the ideal, he only mentions them offhand in the introduction. I don't think this is by coincidence. His reasoning is a subjective value statement that even is followed through by claiming concepts like Promises are "only invented" while better ones (he obviously means observables) are "discovered". This claims that Promises are something "unnatural" and flawed and observables are "natural" and flawless.

There is a certain kind of thinking I sometimes call "single minded" - which is perhaps a special kind of cognitive dissonance which can only accept single concepts in a particular problem space. Being unable to accept pluralism as a result.

Yes concepts like observables are more suitable to some use cases than promises. It could be argued though that promises might be easier to understand or use for many JS programmers today. It might be that promises disguised behind async/await is easier to understand and use than observables. I don't know - thats just a subjective perception. One thing is clear though: In a bigger JS ecosystem the concept of promises is much more common and therefore interaction of APIs and thirdparty modules suits to them quite well. Though - since promises can also be consumed by observables this ain't not such a bad thing - its called "options", "choice" or... pluralism.
city41 296 days ago. link 3 points
The author is basically wishing promises were observables. I really like that they aren't. To me, then() being both map() and flatMap() is one of the killer features about promises. I find having both functions in observables really makes them a lot more finicky to use.  
Promises are an abstraction on top of callbacks. A callback based function is also eager. Once you invoke it, you're off to the races. Same thing with creating a promise. I don't see this as a bad thing.

Promises aren't cancelable, but neither are callback based functions. 

I like promises just the way they are. The fact that they lend themselves so well to async/await shows they are well designed IMO.