4 ms·

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 com

by e12e 4y 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?

aparks517 4y ago
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! ;)
- chrismorgan 4y ago
  > which I /think/ both have Fetch Yes: https://caniuse.com/fetch https://caniuse.com/fetch.
dreamcompiler 4y 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-promises.html https://pouchdb.com/2015/05/18/we-have-a-problem-with-promis...
- mhink 4y ago
  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.
  - dreamcompiler 4y ago
    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 ;-)
nemothekid 4y ago
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
- easrng 4y ago
  You need to consume the body stream manually: https://fetch-progress-demo.glitch.me/ https://fetch-progress-demo.glitch.me/

by e12e 4y ago

aparks517 4y ago

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

chrismorgan 4y ago
> which I /think/ both have Fetch Yes: https://caniuse.com/fetch https://caniuse.com/fetch.

dreamcompiler 4y 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-promises.html https://pouchdb.com/2015/05/18/we-have-a-problem-with-promis...

mhink 4y ago
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.
- dreamcompiler 4y ago
  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 ;-)

nemothekid 4y ago

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

easrng 4y ago
You need to consume the body stream manually: https://fetch-progress-demo.glitch.me/ https://fetch-progress-demo.glitch.me/