Hacker News new | ask | show | jobs
by dreamcompiler 1459 days ago
I still use xhr because of familiarity. Using a javascript closure as a callback in xhr works quite well and seems much easier to me than dealing with the promises that are required for fetch. (I understand what promises are; I just think the ones in javascript are poorly-defined.)

https://pouchdb.com/2015/05/18/we-have-a-problem-with-promis...

1 comments

From the end of the article you linked:

> Awaiting async/await

> That's the point I made in "Taming the asynchronous beast with ES7", where I explored the ES7 async/await keywords, and how they integrate promises more deeply into the language. Instead of having to write pseudo-synchronous code (with a fake catch() method that's kinda like catch, but not really), ES7 will allow us to use the real try/catch/return keywords, just like we learned in CS 101.

> This is a huge boon to JavaScript as a language. Because in the end, these promise anti-patterns will still keep cropping up, as long as our tools don't tell us when we're making a mistake.

Async/await is extremely well-supported and reliable in the ecosystem now, and allows you to express Promise-based asynchronous flows with a much more natural syntax. I highly recommend that you take a look, as it pretty much obviates all the pain points mentioned in the linked article.

I'll do that. The whole promise chaining thing seems very awkward to me, and I stopped investigating promise-based solutions because I was under the impression that "everybody" preferred promise chaining to async/await. Maybe that's exactly the reason I might prefer async/await ;-)