Hacker News Reader

Comment by drewgross | Hacker News Reader

Because it blocks anything else from happening. If on a server, it will prevent that process from handling any requests until the file has been read, and in a browser-like environment it will prevent the UI from updating and will prevent all UI interaction until the file has been read.

In a simple script you run from your shell, the middle one is fine.

View on HN

Thank you. I can see the advantage of Promises and async/await. But most of the time, I want to read the file right now, or define what should happen after it has been read. I can not imagine any circumstance when I maybe want to read a file later witch I think is the only advantage of Promises over callbacks, EventEmitter and Sync.

I think it's perfectly fine to wrap standard nodeJS modules into your own module, Promisify or what not. Almost all NodeJS modules does actually use standard modules in some way, it would be very naive to suggest that the standard library should start returning Promises, as it would break almost every NodeJS module ever created.

I also think that Promises only makes sense when you only expect one return, it would note make sense to use Promises in NodeJS streams.

Because it makes points of potential interleaving obvious. Without await, you have no idea whether the call will block or not, and whether whatever shared state you accessed before the call will remain the same after.

With await, you know. If there is no await, the call will not block, and more importantly, shared state cannot be modified from outside of that block of code. If there is await, there are no guarantees and you need to take the necessary precautions.

Reply on news.ycombinator.com