Hacker News new | ask | show | jobs
by e12e 1458 days ago
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?
3 comments

Thank you for your kind words! For lofi.limo I support back to Chrome 49 and Firefox 52 (the last versions available for Windows XP), which I /think/ both have Fetch, so I could have probably used it here.

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! ;)

> which I /think/ both have Fetch

Yes: https://caniuse.com/fetch.

The only thing I’ve seen that I’ve hit recently is fetch doesn’t have a progress API.

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

You need to consume the body stream manually: https://fetch-progress-demo.glitch.me/
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...

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 ;-)