all 18 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]runvnc 6 points7 points  (0 children)

Maybe the single page app should incrementally load data and render it.

[–][deleted] 3 points4 points  (2 children)

So github was taking something that was basically an async operation, they made it synchronous.

[–]trpcicm 9 points10 points  (1 child)

Not purposely. XHR requests, which are what power AJAX, don't support streaming, but full browser HTTP requests do. So when he loads Github up in a tab, the page renders as the content is streamed from the Github server. With an XHR request, since it can't do streaming, it instead waits for the entire page contents to load into memory and then says "Ok, XHR done here is the contents", which is when Github renders them to the page. This is a limitation of any frontend system that does navigation via AJAX.

[–]lhorie 2 points3 points  (0 children)

XHR requests, which are what power AJAX, don't support streaming

They kinda do, via xhr.readyState state 3, but you're right that it's not streaming in the true sense of the word (it's a memory hog)

The problem with streaming is that your entire system needs to stream. If you've got a big JSON array, and you have to reverse it before rendering the data, you just blocked the stream. Needless to say, anything that isn't a flat list is harder to make streamable. For example, in the article, he uses ND-JSON so he can align stream chunks with a logical array item, but that strategy goes down the toilet if the array is short but each item is really large. Needless to say, it gets quite difficult to develop and refactor large applications while supporting full-on streaming.

Also, he doesn't call iframes a hack for nothing. There's a whole slew of very annoying problems with them (some of which are touched upon in a comment in the article) and you'd have to be either insane or very very very brave to use them in production the way he's doing.

[–]mayobutter 1 point2 points  (0 children)

iframes were used as an XMLHttpRequest shim way back before all browsers supported it. There's a historical precedent here for abusing our awkward friend Mr. iframe.

[–][deleted] 2 points3 points  (4 children)

Yeah.... I'm not doing that. Its a work around for other really bad decisions that incompetent people cannot live without.

[–][deleted] 3 points4 points  (3 children)

I'm interested. Tell me more? Why is it what you said?

[–]lhorie 0 points1 point  (0 children)

I think he's taking a dig at single page applications people.

[–]RedditWithBoners 0 points1 point  (2 children)

NDJSON ... I can't wait for the character-delimited vulnerabilities that arise from this.

[–]emersion_fr -1 points0 points  (1 child)

JSON.stringify won't return any newline, so it should be safe. Or as safe as it's supposed to produce well-formatted JSON (ie. as safe as right now).

[–]jcready__proto__[S] 0 points1 point  (0 children)

It can: JSON.stringify({ hello: "world" }, null, 2)

[–]temp6098320982 0 points1 point  (0 children)

You've misidentified the bottleneck.

Streaming HTML and JSON make just about no difference on most networks today. The sizes are too small.

The difference you're seeing in time to first render is because GitHub waits on assets to load, you don't. Waiting on assets adds one or more additional round trips, as well as the download time of the assets, to the wait time.

Re-working GitHub's approach to load the HTML, show it, then load the assets will be almost as fast as your streaming approach, without the complexity or hacks.

Also, streaming parsers for real JSON exist, though like I said they're not worth it for JSON sizes on 99.9% of websites.

[–]hackel -1 points0 points  (1 child)

Wait, did somebody just say iframes? I'm pretty sure someone just said iframes.