Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish

github.com

Post reply on HN
Print view View original

51–60 of 74 posts

Re: Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish

#51

Post by ianstormtaylor »

joombar wrote: post #30
alessioalex wrote: post #28

This is basically node-trumpet in the browser. Really great stuff! https://github.com/substack/node-trumpet

Hadn't seen that before. Interesting link, thanks. Very similar except JSON/JSONPath instead of HTML/CSS. Oboe runs fine in Node but I want to make the code a bit more standards-y. Ie, using Node's EventEmitters instead of the little pubsub I made for the browser.

Random tangent: no need to make your own pubsub by the way. I figure you might be interested in component[1]. Makes writing libraries like oboe even easier because all of the little stuff is packaged up for you already, like emitter[2]. And then tons of the little helpers in oboe could easily be their own components and useable by others. Check out the full list[3].

[1]: https://github.com/component/component

[2]: https://github.com/component/emitter

[3]: https://github.com/component/component/wiki/Components

Re: Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish

#53

Post by joshfraser »

This makes a lot of sense. Latency is the #1 enemy on mobile, but bandwidth tends to be relatively okay. That's why streaming a video to your phone feels surprisingly fast, while everyday browsing feels sluggish. The obvious conclusion is to use fewer but larger requests, which is why Oboe is so attractive.

Re: Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish

#55

Post by joombar »

freework wrote: post #47

This is great for that 1 time out of 1,000,000 when you have an ajax call that would benefit from a tool like this. In the overwhelming majority usecase, this oboe.js thing is not going to be a "plug it in, automatically webscale" type of optimization. I'm not trying to rag on the authors of this project, but the wording of this submissions is going to lead noobs to mis understand the benefit. The authors should inst…

It should make most calls faster. Exceptions are for small JSON files or on networks that are fast enough there is no streaming effect (the whole file arrives very quickly)

For most sites there'll be some users where it will make it faster (mobile, slow internet) and others that it'll be about the same. If the network is unreliable it should help as well because when the connection drops you don't lose what you already downloaded.

"makers" = just me :-)

Re: Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish

#56

Post by joombar »

tambourine_man wrote: post #16

This probably won't work if you have gzip on, right?

Quick experiment says: Gzip can be written out as a stream ok. Can't comment on Apache but Node does it fine.

Firefox's xhr fires progress events for gzipped content but not Chrome's. Looking to see if I can find a way round it.

Re: Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish

#57

Post by joombar »

joombar wrote: post #56
tambourine_man wrote: post #16

This probably won't work if you have gzip on, right?

Quick experiment says: Gzip can be written out as a stream ok. Can't comment on Apache but Node does it fine. Firefox's xhr fires progress events for gzipped content but not Chrome's. Looking to see if I can find a way round it.

In meantime, made a bug report: https://code.google.com/p/chromium/issues/detail?id=309092

Re: Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish

#59

Post by samspot »

sequoia wrote: post #10

This looks really cool! I'm confused about the usecase, however. In your foods/nonfoods example[0], it allows you to request a some JSON with 2 keys, `foods` and `"nonFoods"`, each with an array value, and use only foods, discarding nonFoods. You request this from oboe('/myapp/things.json') My question: why not modify the backend to accept a request like `/myapp/foods.json` and let the backend compose the json you ne…

I am often consuming API's that I have no control over, and this is great for that use case.

Re: Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish

#60

Post by stuaxo »

joombar wrote: post #36
k3n wrote: post #34

I was wondering when some of these types of libs might make their way into the world, I know I saw in Nicholas Zakas' book "High Performance JavaScript"[1] that he demonstrated how to read back (process) a large AJAX result in chunks, allowing you to begin working with the response before it was finished downloading. It was called "multipart XHR", and he shows a neat code example and then links to a site that has sam…

I haven't looked at MXHR but here's roughly what Oboe does: 1 Create XHR, listen to XHR2 progress event. 2 Use Clarinet.js SAX parser, scoop up all events. 3 From SAX events, build up actual JSON and maintain path from root to actual node. 4 Match that path (+ some other stuff) against registered JSONPath specs. 5 Fire callbacks if they pass.

Awesome, I've been waiting for a library exactly like this :)
Post reply on HN