4 ms·

I work with fairly large JavaScript codebases, and the issues mentioned in the post has never been an issue for me. The switch from callbacks to Promises, and l

I work with fairly large JavaScript codebases, and the issues mentioned in the post has never been an issue for me. The switch from callbacks to Promises, and later to async-await has made a massive improvement to the ease of writing, reading and maintaining the code. Lazy and cancellable tasks are edge-cases that don't need support in Promises directly. I haven't needed either of those in more than a couple of places in the code, versus thousands of places where Promises are used as is. I can see the automatic unwrapping of Promises to be an issue in some libraries that want to make specific guarantees, but in most of my code this has behaviour has simplified things. I definitely prefer having Promises and async-await right now over another theoretically sound (but probably more verbose) system available in a couple of years.

z3t4 9y ago
I think Promises=>async/await works great for certain domains like get a value from a database, them make an insert, then do something else and then return a message to the user. I however write a lot of systems where almost all operations need to be concurrent, cancelable and rate-limited. Personally I find callbacks and the event loop easy to reason about, but too daunting when all you do is CRUD requests to a database. The problem with Promises though is that they spread, they don't like to live side by side with other async paradigms.
yuchi 9y ago
100% agree. In my (more or less extensive) experience missing cancellation is what bites you more. Not because Promises don‘t implement it (I worked a lot with bluebirds CancellablePromises a lot and… it’s not fun) but because there’s no unified, “standard” and “specced” way. AbortControllers (which are just abort tokens hidden as EventEmitters) are not that bad but we’ll have to wait a lot before all fetch implementation support it (I’m looking at you V8 and Safari!). I still don‘t understand why they didn’t called it CancelController since “abort” is such an overlodaded term. Also (still in my experience) cancellation is incredibly more complex than it could seem. You don‘t want to simply stop the synchronous propagation, you want to act on it! You resources to be freed, you want partially completed async process to rollback what has already been done. Not easy.

z3t4 9y ago

I think Promises=>async/await works great for certain domains like get a value from a database, them make an insert, then do something else and then return a message to the user. I however write a lot of systems where almost all operations need to be concurrent, cancelable and rate-limited. Personally I find callbacks and the event loop easy to reason about, but too daunting when all you do is CRUD requests to a database. The problem with Promises though is that they spread, they don't like to live side by side with other async paradigms.

yuchi 9y ago

100% agree. In my (more or less extensive) experience missing cancellation is what bites you more. Not because Promises don‘t implement it (I worked a lot with bluebirds CancellablePromises a lot and… it’s not fun) but because there’s no unified, “standard” and “specced” way. AbortControllers (which are just abort tokens hidden as EventEmitters) are not that bad but we’ll have to wait a lot before all fetch implementation support it (I’m looking at you V8 and Safari!). I still don‘t understand why they didn’t called it CancelController since “abort” is such an overlodaded term. Also (still in my experience) cancellation is incredibly more complex than it could seem. You don‘t want to simply stop the synchronous propagation, you want to act on it! You resources to be freed, you want partially completed async process to rollback what has already been done. Not easy.