Use streaming JSON to reduce latency on mobile

I agree that a streaming response is cool, but why the dismissal of returning valid JSON, streamed? Why invent a new protocol when JSON already exists? Streaming JSON parsers aren&#x27;t unicorns, they are horses (sorry).<p>With this new-line-delimited JSON format all your clients HAVE to know about your new protocol. They have to stream the response bytes, split on new lines, unescape new lines in the payload (how are we doing that, btw?), etc. If a client doesn&#x27;t care about streaming, it can&#x27;t just sit on the response and parse it when it&#x27;s done coming in. Or, how about if later on you upgrade the system so that the response is instant and streaming is no longer necessary? Then you move on to a new API and have to keep supporting this old streaming-but-not-really endpoint forever.

Somewhat related is the JSON Lines &quot;spec&quot;: <a href="http:&#x2F;&#x2F;jsonlines.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;jsonlines.org&#x2F;</a>

I have nothing but praise to this service. It&#x27;s fast and efficient, and does the job without bloat.<p>For instance, their iOS app weighs 888.8 KB! When it&#x27;s common for simple apps to be 50 MB monsters, it&#x27;s very refreshing to use something that has been developed with proper care.

You say that using websockets was less reliable than streaming HTTPS, can you elaborate why? In my experience websockets are perfect to use for the use case you described, are there disadvantages?

As someone who <i>actually</i> regularly uses a slow mobile connection (8 kilobytes per second!) with somewhat high ping (~90ms to Google), please don&#x27;t do this thinking you&#x27;re making my life significantly better. It barely makes a difference in performance once loaded, and the initial load time is <i>ridiculously</i> worse. I&#x27;d much rather you make your page work <i>without JavaScript</i>, kept the design light (as this page has otherwise done), and make your CSS cacheable.<p>Right now, it takes over 5 seconds(!!) for this page to load because of all the freaking JavaScript it has to download! With JS off, the page loads <i>almost immediately</i>. With a keep-alive connection, subsequent loads over HTTPS are not particularly long, unlike what this article seems to think. (Hacker News is one of the FASTEST sites I can access, for example. Even on my crappy connection, pages load nearly instantly.)<p>Simply letting me type, press enter, and wait 0.1~0.3 seconds for a new page response would not be a significantly worse experience -- however, due to the way the site is written, search doesn&#x27;t work AT ALL with JS disabled.<p>So, lots of engineering effort (compared to just serving up a new page) for little to no actual speed improvement, and a more brittle website that breaks completely on unusual configurations... Yeah. Please don&#x27;t do this!

Really interesting stuff! What about simply opening a Websocket connection and using that to for all requests if connection latency is such an issue?

I did this a few years ago before I knew it was a &quot;thing&quot; and felt really proud that it actually worked.<p>The use-case was we had a slow database query for basically map pins. The first ones pins come back in milliseconds, but the last ones would take seconds. The UI was vastly improved by streaming the data instead of waiting for it all to finish, and the server code was easy to implement.<p>A different delimiter would have worked, but newlines are easy to see in a debugger.

I&#x27;d like to see this streaming JSON parser incorporated into GraphQL clients: <a href="http:&#x2F;&#x2F;oboejs.com" rel="nofollow">http:&#x2F;&#x2F;oboejs.com</a>

Any benefit to using this over Server-Sent Events? (other than IE&#x2F;Edge support)

I think websockets is a much better use case for this if you don&#x27;t want the reconnection overhead. Also since websockets are bidirectional, you can keep the connection open and send all requests through the connection as well as receive responses from the connection. Also you can send binary on websockets if you want to save bandwidth as well. We do this at work and it works pretty nicely.

How is this handled from a UI perspective? As more applications are built around the idea of streaming data, I&#x27;ve found that UI elements tend to jump around, and I find myself clicking&#x2F;tapping the wrong item more and more, because the item which had been under my thumb&#x2F;cursor has jumped away just before I could activate it.

Isn&#x27;t this pretty similar to how you would use WebSocket frames to transfer individual JSON elements when a client is subscribed?<p>At one job I had several years ago we came up with the same idea and use \n separated JSON elements as a streaming response. We also tossed around the idea of using WebSockets to stream large responses between services.

Let&#x27;s talk about reliability: The network is unrealiable; Firewalls might be broken, packets are dropped, IP-addresses may change, cellphones lose connection in subway tunnels. Simply calling &quot;streaming reliable&quot; without even defining what the &quot;reliability&quot; is protecting again, makes &quot;reliable&quot; an overstatement.<p>IMHO the most reliable way to get data from point A to point B is likely by having a client actively polling for data, using a strict socket timeout. Data should be at-least once delivered. If JSONS should be called anything remotely &quot;reliable&quot; as periodically polling, at least it should have a strict timeout (not mentioned in the article) for receiving the next newline &amp; it should handle replaying of non-acked messages. Otherwise I would call it far from &quot;reliable&quot;.

Does anyone know a JSON parser that parses an ArrayBuffer instead of strings? [1]<p>JSON.parse() only accepts strings.<p>The library that the article recommends also uses XMLHttpRequest with strings. [2]<p>The reason I&#x27;m asking is the maximum string length in 32-bit Chrome.<p>[1]: <a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;API&#x2F;XMLHttpRequest&#x2F;responseType" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;API&#x2F;XMLHttpRequ...</a><p>[2]: <a href="https:&#x2F;&#x2F;github.com&#x2F;eBay&#x2F;jsonpipe&#x2F;blob&#x2F;master&#x2F;lib&#x2F;net&#x2F;xhr.js" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;eBay&#x2F;jsonpipe&#x2F;blob&#x2F;master&#x2F;lib&#x2F;net&#x2F;xhr.js</a>

If the concern is HTTPS overhead, why not use HTTP&#x2F;2 and send multiple requests?<p>I think streaming would be useful only if the responses are stateful and it&#x27;s hard to share it across requests.

Feels to me like the response content type shouldn&#x27;t be &quot;application&#x2F;json&quot; anymore (it is what&#x27;s returned on that first example).

Is there an advantage to using chunked streams like this over using WebSockets like this: <a href="https:&#x2F;&#x2F;github.com&#x2F;wybiral&#x2F;hookah" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;wybiral&#x2F;hookah</a> (this will take newlines from a programs stdout and send them over WebSockets, even aggregating multiple streams into one).

I feel like I&#x27;m missing something here. Isn&#x27;t that the point of using a JSON SAX parser instead of a DOM parser?

How is this different than SSE <a href="https:&#x2F;&#x2F;html.spec.whatwg.org&#x2F;multipage&#x2F;comms.html#server-sent-events" rel="nofollow">https:&#x2F;&#x2F;html.spec.whatwg.org&#x2F;multipage&#x2F;comms.html#server-sen...</a> ? Or, why would someone choose this over SSE?

Why not just gzip the JSON? Should make complicated JSON around an order of magnitude smaller, and be more portable to boot.

Why would you use this over web sockets?

Should have (2017) in the title.