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

41–50 of 74 posts

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

#41

Post by k3n »

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.

Interesting. After looking at the MXHR more, it appears as though it was adapted from Digg.com[1] (aka DUI.Stream[2]), and then later adapted by Facebook[3].

Yours sounds more elegant in that it can handle JSON naturally, but I wonder if the other might be better suited for binary content (not sure in which context that would make sense, if any).

Either way, I find them all fascinating, and I've starred your project :) Will keep an eye on it.

1. http://techfoolery.com/mxhr/mxhr.js

2. https://github.com/digg/stream

3. https://www.facebook.com/note.php?note_id=183263890703

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

#42

Post by joombar »

alessioalex wrote: post #32
joombar wrote: post #30

Earlier quoted context omitted.

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.

It would be really nice to have the same streaming interface (with EventEmitters) as Node, but you I can just shim that on top of Oboe I guess. It would be great to have the same patter as in Node. Btw what are you using for the Node side, JSONStream? https://github.com/dominictarr/JSONStream

There's only a node side so far as I needed to write for some component tests. It'd work with anything that writes out valid JSON.

The client side works in Node right now as well as in the browser but it is a bit browser-y. It is on my home office Agile board to make it a bit more node-y.

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

#43

Post by mbrock »

tambourine_man wrote: post #33
joombar wrote: post #21

Earlier quoted context omitted.

I'll have to test to be sure you still get streaming. It depends how the browsers handle xhr2 events with regard to gzip'd http. I /think/ it'll be fine but I need to check to be sure. Eg, with gzip on you still get progressive html rendering.

From what I remember, Apache will send you a single chunk if you have it on, for example: '; flush(); ob_flush(); sleep(20); echo 'Bye'; ?> Will send you "Hey Bye" after 20sec instead of what you would expect (which does work with gzip off). Besides, even if you manage to stream it, I imagine inflating partially received content is not trivial for the browser.

Gzip is a streaming format -- it's designed as a compressed format for communication streams. Browsers have no trouble with this. The Apache behavior you describe is probably related to buffering settings, which I think can be configured.

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

#44

Post by camus2 »

dustingetz wrote: post #2

At the very bottom he describes the use case. Mobile apps optimize for battery life by preferring one big long request up front rather than lots of little ones as needed. But you only need the first 10% of the data to render the first screen of your app.

You might want to render the first screen of your app without any ajax call. That's the best thing to do. There is no reason why your app cant render with datas directly.

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

#45

Post by the_gipsy »

jastanton wrote: post #31

So if you're streaming in the JSON this program must have a custom JSON parser because there would be no way to assure valid JSON on an incomplete payload. Am I understanding how this works correctly? edit: Also how is this faster, if you're parsing an incomplete response over and over again isn't each parse blocking, wouldn't this approach kill your FPS?

Yes, it uses SAX which seems to fire events as nodes get parsed. I don't think that the response, or any node of the JSON string of the response, gets parsed more than once.

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

#47

Post by freework »

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 instead emphasize the usecase where an actual benefit comes out of using this library, instead of just saying "it makes your ajax faster!!"

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

#48

Post by joombar »

k3n wrote: post #41
joombar wrote: post #36

Earlier quoted context omitted.

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.

Interesting. After looking at the MXHR more, it appears as though it was adapted from Digg.com[1] (aka DUI.Stream[2]), and then later adapted by Facebook[3]. Yours sounds more elegant in that it can handle JSON naturally, but I wonder if the other might be better suited for binary content (not sure in which context that would make sense, if any). Either way, I find them all fascinating, and I've starred your project…

I suppose you could make a binary equivalent if you needed to. You'd need to make some kind of binary matching language, maybe like Erlang's binary matching.

Adding XML/XPATH support would be a natural extension.

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

#49

Post by sequoia »

joombar wrote: post #25
sequoia wrote: post #18

Earlier quoted context omitted.

Yeah! There are more understandable examples further down. suggestion @joombar: since the first example is the first thing people see and it doesn't actually reflect the core usecase, perhaps add a note explaining that the example is contrived for simplicity's sake ~or~ make the primary example represent the core usecase more closely. Cool project!

Hmmmm, yeah. Use cases doesn't take up much space, I'll put that before examples because it explains better what it is for.

OH yeah!! Those user-story style use cases really help clarify what it's for in a clear succinct way. Thank you!! (I wish all projects would do this)

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

#50

Post by joombar »

alessioalex wrote: post #37
joombar wrote: post #11

Earlier quoted context omitted.

No worries. This is my masters dissertation btw.

What exactly is the title of your dissertation? (just curious)

Liable to change but "An approach to i/o for rest clients which is neither batch nor stream; nor SAX nor DOM." I'm writing it now.
Post reply on HN