• Max-P@lemmy.max-p.me
    link
    fedilink
    arrow-up
    8
    ·
    edit-2
    6 months ago

    XHR is absolutely ancient. Like, I used it on Internet Explorer 6 era websites. Using a 3x3 table with images in all 8 outer cells to make rounded corners.

    It still works but is so old it can’t really be updated. It’s entirely callback driven so no async. It’s not even async by default if I recall correctly, it just hangs the browser.

    The Fetch API was designed to modernize what XHR does, and does so well. Now, a simple get request you can pretty much await fetch(...) whereas the XHR one is probably 20-40 lines of code and most people end up using a library to deal with it, or write their own little wrapper for it. It supports promises natively.You can stream very large files without loading it all in memory. There’s nothing XHR can do that fetch can’t do, and usually does it better too. For most use cases the performance will be the same, network IO is orders of magnitude slower than JavaScript execution. But the API being better probably does lead to better performance by not doing unnecessary things and possibly processing data as it arrives instead of all in one go when the download is finished.

    It’s a modern replacement because it’s literally what it was designed to be. Try both and it’ll be abundantly clear why.

  • walter_wiggles@lemmy.nz
    link
    fedilink
    arrow-up
    1
    ·
    6 months ago

    I think of XHR as more of a low-level API. Most of the time though you don’t need access to those low-level details.

    The fetch API is bit higher level and nicer to work with.