Very nice write-up. I'd be curious to see it using fetch rather than the older xhr Api - that would make more sense as a library today I think? Or are there compelling reasons to stick with xhr in a post-ie world?
Fetch has about the same capabilities as XHR, so it should be a drop-in replacement in this project. Let's call it an exercise for the reader! ;)
Use case: I was fetching a large image from a server to render into a canvas and I wanted to show a progress bar for the download. AFAIK there is no way to do this with fetch
https://pouchdb.com/2015/05/18/we-have-a-problem-with-promis...
> 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.