3 ms·

No, the right way is to fix the fetch() api to not return a promise and reflect on why the system was so broken that fetch() api was released with such an obvio

by ralfn 10y ago

No, the right way is to fix the fetch() api to not return a promise and reflect on why the system was so broken that fetch() api was released with such an obvious flaw. Because Promises don't need to be cancellable. This has nothing to do with promises. Fetch requests need to be cancellable. But they, in all their wisdom, decided that the fetch API returns a promise. So now promises need to become whatever the hell the fetch API actually needs to return. You would almost think design by committee is fundamentally flawed, and design by community even more flawed. Because the edge cases are never obvious. For every new feature the question shouldn't be "do i make 99 programmers 1% happier?", but do i make 1 programmer cry upto the point where they would stab my eyes out if they could? We've all been that 1 programmer, and yes, i would if i could. It's a clusterfuck of bike shedding. Most new ES2016 have details that haven't been though through and will end up being hated on the same level as '==' and 'NaN'. The dev-leads of the different javascript engines should not just be able to veto. They should be able to veto people out of the room, out of the debate. And we should celebrate it every time they take advantage of that power. Or just give up on Javscript all together and just let the rot fester.

cwmma 10y ago
> The dev-leads of the different javascript engines should not just be able to veto. They should be able to veto people out of the room, out of the debate. And we should celebrate it every time they take advantage of that power. Or just give up on Javscript all together and just let the rot fester. this would ironically tend to be applied to people like you
- ralfn 10y ago
  No irony :) I don't think i should be in that room. I know enough to know how little i know. I also know enough to recognize a naive short sighted proposal such as 'cancellable promises'. That doesn't mean it should be me dismissing that feature. But i am very much smiling that the people that should be in that room, did dismiss it.
jrochkind1 10y ago
I think fetch definitely needs to (at least as an option) offer some kind of async API built-in without adding another dependency. Async is likely the most common use case in the browser. I have not been displeased with the fetch->promise API, it works well for me, and is definitely a lot more convenient than XMLHttpRequest. Which part do you disagree with from your experience?
- ralfn 10y ago
  I love the fetch-api as well, but it doesn't allow for one to cancel the request. Which is why people want to change Promises in the first place. Because the committee in all its wisdom has specified that the fetch-api returns a promise. So the only way to make the requests of the fetch-api cancellable is to change the return type of the fetch-api. But that has been standardized to be a Promise. So now they want to change Promises to be whatever the hell they need from the fetch-api. Do i need to cancel requests? Not really. But not being able to cancel requests is now driving a shitstorm of short-sighted proposals to mutate the Promise contract into some sort of 'whatever the hell the fetch-api really needs reply object'.
  - jrochkind1 10y ago
    There's probably a (hypothetical API) way to get a _fetch_ to be cancellable, even though it returns a promise, without altering the API of general promise. Some way to get a reference to the request going on and cancel it, which would result in the promise failing (assuming it hadn't completed yet) with a FetchCancelledError or something. One could certainly imagine building such an API if one were polyfilling fetch onself built on XMLHTTPRequest (which can be cancelled). I won't bother trying to think it through though cause it's clearly pointless except as an intellectual exersize! I actually like that fetch returns a Promise, I find it convenient, I don't think it was a bad choice at all. To make Promise part of ES6 as a general-purpose async primitive, and to make Fetch return one. I also see how it would be nice to allow fetches to be cancelled -- although I'm not sure I've ever needed/wanted to do that, I could see how I might in the future. It is boggling that a bunch of smart interested people haven't been able to figure out _some_ solution to this.

by ralfn 10y ago

cwmma 10y ago

> The dev-leads of the different javascript engines should not just be able to veto. They should be able to veto people out of the room, out of the debate. And we should celebrate it every time they take advantage of that power. Or just give up on Javscript all together and just let the rot fester. this would ironically tend to be applied to people like you

ralfn 10y ago
No irony :) I don't think i should be in that room. I know enough to know how little i know. I also know enough to recognize a naive short sighted proposal such as 'cancellable promises'. That doesn't mean it should be me dismissing that feature. But i am very much smiling that the people that should be in that room, did dismiss it.

jrochkind1 10y ago

I think fetch definitely needs to (at least as an option) offer some kind of async API built-in without adding another dependency. Async is likely the most common use case in the browser. I have not been displeased with the fetch->promise API, it works well for me, and is definitely a lot more convenient than XMLHttpRequest. Which part do you disagree with from your experience?

ralfn 10y ago
I love the fetch-api as well, but it doesn't allow for one to cancel the request. Which is why people want to change Promises in the first place. Because the committee in all its wisdom has specified that the fetch-api returns a promise. So the only way to make the requests of the fetch-api cancellable is to change the return type of the fetch-api. But that has been standardized to be a Promise. So now they want to change Promises to be whatever the hell they need from the fetch-api. Do i need to cancel requests? Not really. But not being able to cancel requests is now driving a shitstorm of short-sighted proposals to mutate the Promise contract into some sort of 'whatever the hell the fetch-api really needs reply object'.
- jrochkind1 10y ago
  There's probably a (hypothetical API) way to get a _fetch_ to be cancellable, even though it returns a promise, without altering the API of general promise. Some way to get a reference to the request going on and cancel it, which would result in the promise failing (assuming it hadn't completed yet) with a FetchCancelledError or something. One could certainly imagine building such an API if one were polyfilling fetch onself built on XMLHTTPRequest (which can be cancelled). I won't bother trying to think it through though cause it's clearly pointless except as an intellectual exersize! I actually like that fetch returns a Promise, I find it convenient, I don't think it was a bad choice at all. To make Promise part of ES6 as a general-purpose async primitive, and to make Fetch return one. I also see how it would be nice to allow fetches to be cancelled -- although I'm not sure I've ever needed/wanted to do that, I could see how I might in the future. It is boggling that a bunch of smart interested people haven't been able to figure out _some_ solution to this.