3 ms·

It’s interesting to me that people are pumped about async/await. If we time travel back to when Node caqme out, the single most common reason I saw cited for i

It’s interesting to me that people are pumped about async/await. If we time travel back to when Node caqme out, the single most common reason I saw cited for its success was something like: “JavaScript’s simple event-based programming model is a natural fit for a server coordinating I/O from different places”. Back then we had callbacks and closures and it was just powerful enough you could do almost anything, but simple enough that you were never truly lost. Now I see developers pumped about a world where callbacks, promises, and async/await are all mixed together in an NPM soup. I wonder if that mixture might be the thing that finally pushes JavaScript out of reach for beginners (if it’s not there already). And maybe that opens a door for something like Lua, if it really can embrace async functions without the baggage of Promises and callbacks spread throughout public repos. Even if that works out though, I do wonder about that original reaction to Node. Maybe Ryan Dahl really hit on a good control flow model that the JS community then threw away. I do think that platform devs sometimes try too hard to make async “disappear” instead of trying to make it inspectable.

namelost 9y ago
Anybody who has used node.js for more than 10 minutes knows that the callback style makes code completely unreadable. Unreadable code is a breeding ground for bugs. Back in 2009, that was an acceptable trade-off, because there were advantages to JavaScript, such as sharing code between client and server. Now we have promises and we don't have to put up with callbacks anymore (eventually!). FWIW async/await is the syntax, and promises are the runtime, they are not competing features.
- erikpukinskis 9y ago
  That’s a really insulting way to argue your point. I’ve been writing JavaScript for 15 years. Full time for probably six years, when I dropped Rails for Node and Ember. Right now I am programming full time in a promise shop for work, so I am very familiar with that. At home I write 100% callback style and find it superior. The worst is when you have to mix the two, which is why NPM is such a shit show, and why I think async/await will only make things worse. If you’re willing to spend a few minutes considering an alternative perspective to your own, you might read this: http://callbackhell.com http://callbackhell.com You say promises are more readable. I do agree promises make it easier to read and write awful code with gnarled architectures. Callbacks force you to name things and separate concerns, which is helpful if your goal is to write good code. If you just want to hack layer upon layer of garbage into the system, as most employers would prefer you do, then promises will help you hold on for that ride longer. Callbacks will break down faster. I think that’s a feature, as it alerts me to architecture problems sooner. But you may prefer less refactoring and a more additive-only programming model, in which case promises will be a useful tool for you.
  - namelost 9y ago
    If your coworkers are so bad, wouldn't you rather get a nice message in your console when they forget to handle an error? With callbacks, error handling is entirely on the honor system. There may well be some situations where callbacks are tolerable, but any time you have to converse with an external synchronous resource like a filesystem, database or REST API, it's just painful. Making a new function (named or otherwise) for each line of code is not good style, in any language.

namelost 9y ago

Anybody who has used node.js for more than 10 minutes knows that the callback style makes code completely unreadable. Unreadable code is a breeding ground for bugs. Back in 2009, that was an acceptable trade-off, because there were advantages to JavaScript, such as sharing code between client and server. Now we have promises and we don't have to put up with callbacks anymore (eventually!). FWIW async/await is the syntax, and promises are the runtime, they are not competing features.

erikpukinskis 9y ago
That’s a really insulting way to argue your point. I’ve been writing JavaScript for 15 years. Full time for probably six years, when I dropped Rails for Node and Ember. Right now I am programming full time in a promise shop for work, so I am very familiar with that. At home I write 100% callback style and find it superior. The worst is when you have to mix the two, which is why NPM is such a shit show, and why I think async/await will only make things worse. If you’re willing to spend a few minutes considering an alternative perspective to your own, you might read this: http://callbackhell.com http://callbackhell.com You say promises are more readable. I do agree promises make it easier to read and write awful code with gnarled architectures. Callbacks force you to name things and separate concerns, which is helpful if your goal is to write good code. If you just want to hack layer upon layer of garbage into the system, as most employers would prefer you do, then promises will help you hold on for that ride longer. Callbacks will break down faster. I think that’s a feature, as it alerts me to architecture problems sooner. But you may prefer less refactoring and a more additive-only programming model, in which case promises will be a useful tool for you.
- namelost 9y ago
  If your coworkers are so bad, wouldn't you rather get a nice message in your console when they forget to handle an error? With callbacks, error handling is entirely on the honor system. There may well be some situations where callbacks are tolerable, but any time you have to converse with an external synchronous resource like a filesystem, database or REST API, it's just painful. Making a new function (named or otherwise) for each line of code is not good style, in any language.