posterus

Async/Await covers the 80% of use cases for async logic in JS. Most people aren't really using promises as multicast references. They don't call `then` in one place, hang on to the promise reference, then call `then` again somewhere else (perhaps to represent a cached value); they call `then` once on the reference because it's just a moment in a composite operation. It's for this reason that I think this library[0] is the more appropriate abstraction for that same 80% of use-cases, as its more memory efficient since you can represent the same composite operation that generates multiple promise references with a single object (a unicast reference instead). I haven't learned Rust but apparently the author bases this on Rust's ownership principle. [0]https://github.com/mitranim/posterus

> You couldn't progressively integrate a traditional framework like Django for example. I dunno here, is Rails a server application library because I can progressively integrate the different components of its total API, e.g. first use ActiveRecord, then adopt rails-api for the frontend, then adopt ActiveView and Turbolinks for the end-user frontend? Or is there different idea of framework at work here? > Lifecycle methods like render, componentWillMount, etc are just callbacks that get fired when you render you a component. I don't think any library is immediately graduated to the class of "framework" the moment a callback is added. But I don't write the code that says when they're called. Backbone is more of a library, for example, since it lets me do all that and it can be progressively integrated into an app too (I can just use models

Maybe A+ promises are the wrong abstraction https://github.com/mitranim/posterus In the case of the article, we're not going to do anything more with the Promise references returned by those fetch calls, but it seems Promises are designed to accommodate an additional use case where that might be useful but which comes at a cost, like handling cancelation out of the box on a general level.

Added more examples and motivations for cancelation: https://github.com/Mitranim/posterus/blob/17c89694ecdce4633f...

Added a readme section on Rx: https://github.com/Mitranim/posterus/blob/17c89694ecdce4633f...

Futures automatically coerce to promises, so yes. Even better, they come with generator-based coroutines that work with futures, and are automatically cancelable: https://github.com/Mitranim/posterus#routine You can even run it with Koa 2 instead of async/await: https://github.com/Mitranim/koa-ring

Pretty much what jrs95 said. If I understand the question correctly, `Future.all` and `Future.race` address exactly this case. [1] https://github.com/Mitranim/posterus#futureallvalues [2] https://github.com/Mitranim/posterus#futureracevalues

Posterus provides coroutines just for that: https://github.com/Mitranim/posterus#routine Posterus coroutines are similar to async/await, but cancelable and free of `await`'s race condition problem (promise can get rejected before `await` attaches a handler).