I got the idea for this project working on data vis. Not all of the data was visible and we wanted to display the first bit of data quicker without waiting for all of it to arrive. We could have just sent the visible bit but it was good to have some data ready in the off-screen section for when the user scrolled.
Before that I worked on a service where we were aggregating 6 or 7 services into a single JSON. Some of the services were quicker than others but because the AJAX lib we were using waited for the whole response they all had to go at the speed of the slowest component.
We could have done multiple requests but it was more elegant to serve a whole page's json in one call. Also, we cached the slow services so they were only sometimes slow.
Actually, you could use it for that, as long as the library actually finishes downloading the file on abort. If you need contents from the file again, you just download it again and as it will already be cached, that operation should be extremely fast.
If you scroll the README file to the bottom you'll find some good use cases that explain it better than I just did :)
My question: why not modify the backend to accept a request like `/myapp/foods.json` and let the backend compose the json you need & send only that? It seems like fixing it "in the wrong place" to build your frontend to accommodate getting the wrong/too much data. Is this a contrived example that isn't the core usecase? This is my assumption.
Is this primarily for 3rd party APIs and legacy codebases where it's impractical to change the response type & updating to e.g. sockets is impractical? Thanks for the cool project, I apologize for my ignorance wrt whatever points I'm missing!
[0] https://github.com/jimhigson/oboe.js#using-objects-from-the-...