Hacker News Reader

Comment by falcolas | Hacker News Reader

Callback heavy languages can be very challenging to think about. They require keeping quite a few disparate pieces in your mental stack all at once.

Promises make this both better and worse, in my experience. In the easy cases, all you have to do is follow the promises syntax, and you can treat it as linear code.

The problem arises when writing non happy path code, you not only have to think about the promises syntax, but about the abstraction it's creating over callbacks. Otherwise, you begin to miss corner cases, create incorrect promises, and in general write code which misbehaves (often silently).

Promises are powerful abstractions, but like all abstractions, they have their leaks. Also like all other abstractions, there are places where you have to fully comprehend the mechanisms underneath them to use them properly.

View on HN

Very true. And as I mention in the article, ES7 async/await should help fix that: http://pouchdb.com/2015/03/05/taming-the-async-beast-with-es...

Well, `async/await` introduces its own set of problems - I've answered questions on SO before where the OP didn't understand why they got degraded performance when they were doing `await` in a for loop instead of doing things concurrently. At the end of the day you still have to understand promises in order to use `async/await`

That's a fair point, but I think the name itself ("await") tends to communicate the the operation might take a long time. Compare that to multithreaded languages like Java, where it's not obvious that FileInputStream/HttpClient/etc. could take a long time!

Anyway, the big benefit of async/await, to me, is that you really DON'T have to understand promises. :) For instance, at some point we will probably add ES7 examples to the PouchDB API docs (e.g. here: http://pouchdb.com/api.html#create_document), and you can imagine that, from the user's perspective, the word "await" will just be part of the API (e.g. `var doc = await db.get('id')`), and beyond that, they won't have to learn anything about promises or async or callbacks or any of that.

What happens when they have to perform two things that are unrelated and suddenly their performance is down the drain because they `await`ed them all?

I like doing stuff like

  function ensureFoo() {
    let promise = Promise.resolve();
    
    if (!foo) {
      promise = getFoo();
    }
    
    return promise;
  }

Shoudn't you store the initial fooPromise and use it instead?

    var ensureFooEquivalent = getFoo();

Sometimes the data you want is already available - no need to make an extra request in those cases.

Didn't you mean to `Promise.resolve(foo)`? It's also generally safer to cache promises and not values to avoid race conditions (multiple requests).

Check lodash's memoize method

Or don't, as it requires adding an extra library.

Lodash provides separate packages: https://www.npmjs.com/package/lodash.memoize

In my experience, whenever you having trouble with callbacks/promises - it is time to refractor your code. Essentially, this JavaScript nature force you to write code with more code blocks, which is in the end very beneficial to testing.

Reply on news.ycombinator.com