4 ms·

I totally agree with the author here, but also would love to give some context since we have lived something like this before on Javascript IMHO: Callback hell

I totally agree with the author here, but also would love to give some context since we have lived something like this before on Javascript IMHO: Callback hell around 2015. It used to be that if you wanted to do something async you'd have to create a new callback. This led into callback hell[1], which was specially bad back then on the backend. Luckily after a migration that has taken many years, now most of the libraries use async/await instead of callbacks. There was some time where this was extra difficult because some code was using callbacks and some other code was using async/await, but it's almost totally solved in 2020. Which brings us to the article on hand. This is probably one of the biggest issues, and a fake promise in Javascript right now: reuse code on the back-end and front-end. The front-end side has been using `import` for almost a decade with Webpack and friends but this was not easy on the back-end, so there was not a practical way of reusing the code in a project. Luckily since last year Node.js supports import/export, and React supports it in libraries. It took a while because it was not an easy issue. I expect that more and more libraries will start to work only with import/export, and hopefully in 1-5 years this will also be a non-issue. [3] http://callbackhell.com/ http://callbackhell.com/

wvenable 6y ago
> Luckily after a migration that has taken many years, now most of the libraries use async/await instead of callbacks. Is that true? I was looking to port one of my C# projects to TypeScript/Node and it uses gRPC and it's not async/await compatible. That's a pretty major library in my opinion. In the end I didn't end up porting my project because the lack of elegance compared to the C# version was too depressing -- the C# code made heavy use of async and porting without that was just too messy. I'll take another shot at the project once this problem is totally solved.
- yawaramin 6y ago
  Well, it's true for libraries that were using Node-style callbacks ('nodebacks') which had an upgrade path to promises[1] and from there to async/await. If some library was doing a completely different style of async, then unfortunately it won't get that easy migration path but it can probably still use the Promise constructor[2] to wrap the async operation in a promise. [1] https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_util_promisify_original https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_... [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/Promise https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- status_quo69 6y ago
  You can usually promisify the functions that take a callback via util.promisify (although I've done it manually myself as well).
  - shp0ngle 6y ago
    actually not the gRPC functions, since they have options argument with `onEnd` key with callback. So you need to promisify those manually.
- throwanem 6y ago
  I don't know which library you were looking at, but if it wasn't https://github.com/protobufjs/protobuf.js https://github.com/protobufjs/protobuf.js, it probably should be. That one uses promises, so is async/await compatible (JS async/await is just sugar over promises) and I've seen it work well enough in production use to have no reservations in recommending it.
  - wvenable 6y ago
    I googled "grpc typescript" and worked through the first few pages of links. That particular library never came up. I'll take a look.
- franciscop 6y ago
  Yes, I said most and not all, there are still some older libraries that haven't been updated. These are fairly rare, and you can still util.promisify, but sure it's definitely not ideal. Please note that not all callbacks can (or should!) be converted to promises, e.g. events like `on('click', ...)` don't have a clear way to be promisified since a promise can only be resolved once and stays resolved.
  - AbuAssar 6y ago
    observables come handy in such cases
z3t4 6y ago
If you don't want async/callbacks you are using the wrong framework. Serial code is much easier to deal with. And async/await just hides the complexity under the rug, hoping you'll never get backpressure and other issues. Callbacks take a while to grok, it took me about a year to learn how to juggle all the async calls in my head, which a multi threaded language will do for you. Both have their pro et contra though, with multi-threading you'll be dealing with locks.

wvenable 6y ago

> Luckily after a migration that has taken many years, now most of the libraries use async/await instead of callbacks. Is that true? I was looking to port one of my C# projects to TypeScript/Node and it uses gRPC and it's not async/await compatible. That's a pretty major library in my opinion. In the end I didn't end up porting my project because the lack of elegance compared to the C# version was too depressing -- the C# code made heavy use of async and porting without that was just too messy. I'll take another shot at the project once this problem is totally solved.

yawaramin 6y ago
Well, it's true for libraries that were using Node-style callbacks ('nodebacks') which had an upgrade path to promises[1] and from there to async/await. If some library was doing a completely different style of async, then unfortunately it won't get that easy migration path but it can probably still use the Promise constructor[2] to wrap the async operation in a promise. [1] https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_util_promisify_original https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_... [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/Promise https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
status_quo69 6y ago
You can usually promisify the functions that take a callback via util.promisify (although I've done it manually myself as well).
- shp0ngle 6y ago
  actually not the gRPC functions, since they have options argument with `onEnd` key with callback. So you need to promisify those manually.
throwanem 6y ago
I don't know which library you were looking at, but if it wasn't https://github.com/protobufjs/protobuf.js https://github.com/protobufjs/protobuf.js, it probably should be. That one uses promises, so is async/await compatible (JS async/await is just sugar over promises) and I've seen it work well enough in production use to have no reservations in recommending it.
- wvenable 6y ago
  I googled "grpc typescript" and worked through the first few pages of links. That particular library never came up. I'll take a look.
franciscop 6y ago
Yes, I said most and not all, there are still some older libraries that haven't been updated. These are fairly rare, and you can still util.promisify, but sure it's definitely not ideal. Please note that not all callbacks can (or should!) be converted to promises, e.g. events like `on('click', ...)` don't have a clear way to be promisified since a promise can only be resolved once and stays resolved.
- AbuAssar 6y ago
  observables come handy in such cases

z3t4 6y ago

If you don't want async/callbacks you are using the wrong framework. Serial code is much easier to deal with. And async/await just hides the complexity under the rug, hoping you'll never get backpressure and other issues. Callbacks take a while to grok, it took me about a year to learn how to juggle all the async calls in my head, which a multi threaded language will do for you. Both have their pro et contra though, with multi-threading you'll be dealing with locks.