4 ms·

Promises are and always were retarded. They did nothing to alleviate callback hell which was most of the point of their existence. I have no idea why they imple

by slackingoff2017 9y ago

Promises are and always were retarded. They did nothing to alleviate callback hell which was most of the point of their existence. I have no idea why they implemented them instead of async/await in the first place. Now we have to deal with mixing both for years. Another fine example of JavaScript trying to be hip and ignoring the lessons learned from countless other languages over the years. I see this constantly with JS like with the 3+ ways to check for NaN and the object "freeze" system that doesn't actually make objects immutable. They take a solid concept from other languages then put a snazzy spin on it that makes it fucking useless. Then try again in the next version. JS library and syntax is littered with corpses of failed experiments. At least they finally have a usable ForEach loop after three attempts. Please typescript save us from this hubris.

laggyluke 9y ago
You do realize that implementing promises is a prerequisite for async/await, right?
- hderms 9y ago
  Is it really a requirement? I would think callbacks and a preprocessor are sufficient.
  - avaer 9y ago
    Yes, it's a requirement. If you're using a preprocessor you're not supporting async, you're factoring it out. Otherwise the argument collapses to: we don't need any of these features, we just need NAND.
Rockslide 9y ago
You do realise that async/await is basically syntactic sugar for promises in JS, don't you?
buu700 9y ago
How would you propose that async/await work without Promises? Even C#'s async/await uses the same concept: https://msdn.microsoft.com/en-us/library/system.threading.tasks.task.aspx https://msdn.microsoft.com/en-us/library/system.threading.ta... Pending the implementation of new language syntax, raw Promises were a practical solution for what they set out to accomplish. If you don't think they improved callback hell at all, I expect that you probably weren't using them correctly (an easy mistake to make without looking at the documentation and/or reading the wrong tutorials / blog posts). cf. getAsyncValue1(a => getAsyncValue2(a, b => getAsyncValue3(b, c => doSomething(c) ) ) ); and getAsyncValue1().then(a => getAsyncValue2(a) ).then(b => getAsyncValue3(b) ).then(c => doSomething(c) ); Sure, async/await flattens that to zero nested callbacks, which is great, but with that off the table I'd rather deal with code flattened to one level deep (or a few, in some edge cases) than arbitrarily many. And that's just the "callback hell" improvement; don't forget what a nightmare error handling with callbacks can be — you have to handle both synchronous exceptions and error value callback parameters, you have to deal with the possibility of the asynchronous function unexpectedly calling your callback more than once, etc.

laggyluke 9y ago

You do realize that implementing promises is a prerequisite for async/await, right?

hderms 9y ago
Is it really a requirement? I would think callbacks and a preprocessor are sufficient.
- avaer 9y ago
  Yes, it's a requirement. If you're using a preprocessor you're not supporting async, you're factoring it out. Otherwise the argument collapses to: we don't need any of these features, we just need NAND.

Rockslide 9y ago

You do realise that async/await is basically syntactic sugar for promises in JS, don't you?

buu700 9y ago

How would you propose that async/await work without Promises? Even C#'s async/await uses the same concept: https://msdn.microsoft.com/en-us/library/system.threading.tasks.task.aspx https://msdn.microsoft.com/en-us/library/system.threading.ta... Pending the implementation of new language syntax, raw Promises were a practical solution for what they set out to accomplish. If you don't think they improved callback hell at all, I expect that you probably weren't using them correctly (an easy mistake to make without looking at the documentation and/or reading the wrong tutorials / blog posts). cf. getAsyncValue1(a => getAsyncValue2(a, b => getAsyncValue3(b, c => doSomething(c) ) ) ); and getAsyncValue1().then(a => getAsyncValue2(a) ).then(b => getAsyncValue3(b) ).then(c => doSomething(c) ); Sure, async/await flattens that to zero nested callbacks, which is great, but with that off the table I'd rather deal with code flattened to one level deep (or a few, in some edge cases) than arbitrarily many. And that's just the "callback hell" improvement; don't forget what a nightmare error handling with callbacks can be — you have to handle both synchronous exceptions and error value callback parameters, you have to deal with the possibility of the asynchronous function unexpectedly calling your callback more than once, etc.