You can also race it with another promise, which e.g. resolves on timeout.
You can't cancel a JavaScript promise (except sometimes you can)
21–30 of 66 posts
Re: You can't cancel a JavaScript promise (except sometimes you can)
#22[flagged]
Re: You can't cancel a JavaScript promise (except sometimes you can)
#23> Libraries like Effect have increased the popularity of generators, but it's still an unusual syntax for the vast majority of JavaScript developers. I'm getting so tired of hearing this. I loved the article and it's interesting stuff, but how many more decades until people accept generators as a primitive?? used to hear the same thing about trailing commas, destructuring, classes (instead of iife), and so many more.…
There just aren't that many spots where the average js dev actually needs to touch a generator. I don't really see generators ever crossing into mainstream usage in the same way as the other features you've compared them to. Most times... you just don't need them. The other language tools solve the problem in a more widely accessible manner. In the (very limited & niche) subset of spots you do actually need a generat…
It is a specialised instrument but a useful one: batch processing and query pagination are first class use cases for generators that can really simplify business logic code. Stream processing is another and in fact Node.js streams have had a generator API for several releases now.
Re: You can't cancel a JavaScript promise (except sometimes you can)
#24GC can be very slow. Relying on it for control flow is a bold move
I don't think the control flow relies on GC.
The control flow stops because statements after `await new Promise(() => {});` will never run.
GC is only relied upon to not create a memory leak, but you could argue it's the same for all other objects.
Re: You can't cancel a JavaScript promise (except sometimes you can)
#25Re: You can't cancel a JavaScript promise (except sometimes you can)
#26[flagged]
> If I know the javascript ecosystem, and I think I do
You think you do, but...
Re: You can't cancel a JavaScript promise (except sometimes you can)
#27GC can be very slow. Relying on it for control flow is a bold move
Not that very slow for web applications. Maybe for real time or time-sensitive applications. For most day to day web apps GC pauses are mostly unnoticeable, unless you are doing something very wrong
Re: You can't cancel a JavaScript promise (except sometimes you can)
#28The never-resolving promise trick is clever but what caught me off guard is how clean the GC behavior is. Always assumed hanging promises would leak in long-lived apps but apparently not as long as you drop the references.
Re: You can't cancel a JavaScript promise (except sometimes you can)
#29GC can be very slow. Relying on it for control flow is a bold move
as long as there's no leak interrupting a promise should be good for performance overall, not necessarily for the front-end but for the whole chain.
Re: You can't cancel a JavaScript promise (except sometimes you can)
#30> Libraries like Effect have increased the popularity of generators, but it's still an unusual syntax for the vast majority of JavaScript developers. I'm getting so tired of hearing this. I loved the article and it's interesting stuff, but how many more decades until people accept generators as a primitive?? used to hear the same thing about trailing commas, destructuring, classes (instead of iife), and so many more.…
There just aren't that many spots where the average js dev actually needs to touch a generator. I don't really see generators ever crossing into mainstream usage in the same way as the other features you've compared them to. Most times... you just don't need them. The other language tools solve the problem in a more widely accessible manner. In the (very limited & niche) subset of spots you do actually need a generat…
mainly because they messed up on implementation, in two ways. This is of course my opinion.
The first being `.next()` on the returned iterators. If you pass an argument to it, the behavior is funky. The first time it runs, it actually doesn't capture the argument, and then you can capture the argument by assigning `yield` to a variable, and do whatever, but its really clunky from an ergonomic perspective. Which means using it to control side effects is clunky.
The second one how it is not a first class alternative to Promise. Async Generators are not the most ergonomic thing in the world to deal with, as you have the issues above plus you have to await everything. Which I understand why, but because generators can't be used in stead of Promises, you get these clunky use cases for using them.
They're really only useful as a result, for creating custom iterator patterns or for a form of 'infinite stream' returns. Beyond that, they're just not all that great, and it often takes combining a couple generators to really get anything useful out of them.
Thats been my experience, and I've tried to adopt generators extensively a few times in some libraries, where I felt the pattern would have been a good fit but it simply didn't turn out most of the time.