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

61–70 of 74 posts

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

#61

Post by timmaah »

Perfect..

Took me about 10 minutes to add to an existing rails app that adds hundreds of markers onto a google map via json. Live updating as you scroll around.

Previously I was trying to find the sweet spot between how many slows down the initial rendering to the viewer vs showing all the markers.

Changed about 3 lines of javascript to use Oboe and changed my rails controller to:

      per_page = 100
      1.upto(10).each do |page|
        response.stream.write ActiveModel::ArraySerializer.new( resources.paginate(page: page, per_page: per_page) , {root: 'cg'}).to_json
      end
      response.stream.close

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

#63

Post by encoderer »

camus2 wrote: post #44
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.

No reason? You, sir, are lacking imagination.

Here's one: How about the fact in some cases waiting on the latency of a data lookup before rendering the page makes it feel much slower and more sluggish?

In the case mentioned above of map markers, if there's real latency involved in the lookup and you can render the page sans markers and then populate them a couple seconds later, isn't that a superior UI?

Yes, if you are building a simple, moderate or low traffic website/app, it's probably a better practice to render the page with the initial JSON needed. But a lot of the people here are working on products with millions of users -- or just tons of data -- and that changes the equation a bit.

What do you think?

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

#64

Post by currymesurprise »

encoderer wrote: post #63
camus2 wrote: post #44

Earlier quoted context omitted.

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.

No reason? You, sir, are lacking imagination. Here's one: How about the fact in some cases waiting on the latency of a data lookup before rendering the page makes it feel much slower and more sluggish? In the case mentioned above of map markers, if there's real latency involved in the lookup and you can render the page sans markers and then populate them a couple seconds later, isn't that a superior UI? Yes, if you a…

I think you misunderstood your parent's comment.

While the phrasing of the final sentence was awkward, the post was arguing for exactly the same thing as you.

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

#65

Post by jongleberry »

joombar wrote: post #57
joombar wrote: post #56

Earlier quoted context omitted.

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

in my experience, you need to set flush to SYNC for it to work on chrome without manually flushing

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

#66

Post by jongleberry »

jbrooksuk wrote: post #6
joombar wrote: post #5

Earlier quoted context omitted.

No changes required. It should accept any JSON resource. Having said that, there's a much bigger improvement if you're progressively writing out the JSON rather than doing it in one big lump.

Awesome! I'll investigate how easily we can stream our JSON out.

here's a streams2 library for streaming to the client as an array: https://github.com/stream-utils/streaming-json-stringify

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

#67

Post by rurounijones »

timmaah wrote: post #61

Perfect.. Took me about 10 minutes to add to an existing rails app that adds hundreds of markers onto a google map via json. Live updating as you scroll around. Previously I was trying to find the sweet spot between how many slows down the initial rendering to the viewer vs showing all the markers. Changed about 3 lines of javascript to use Oboe and changed my rails controller to: per_page = 100 1.upto(10).each do |p…

What is the resulting speedup to the first marker?

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

#68

Post by joombar »

jongleberry wrote: post #65
joombar wrote: post #57

Earlier quoted context omitted.

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

in my experience, you need to set flush to SYNC for it to work on chrome without manually flushing

Do you know how to do that from node?

Here's the little test service I wrote to stream out some gzipped content:

https://github.com/jimhigson/oboe.js/blob/master/test/stream...

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

#70

Post by joombar »

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?

Well, you could have a JSON which was valid at the start and invalid at the end. It'd parse the first bit ok and only throw an error when it got to the invalid bit.

Nothing gets parsed more than once. SAX parsers already parse streams, they're just not used very much because they're a pain to program with.

Post reply on HN