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

Progressive JSON

overreacted.io

Post reply on HN
Print view View original

81–90 of 244 posts

Re: Progressive JSON

#81

Post by motorest »

vinnymac wrote: post #52
goranmoomin wrote: post #29

Seems like some people here are taking this post literally, as in the author (Dan Abramov) is proposing a format called Progressive JSON — it is not. This is more of a post on explaining the idea of React Server Components where they represent component trees as javascript objects, and then stream them on the wire with a format similar to the blog post (with similar features, though AFAIK it’s bundler/framework speci…

I already use streaming partial json responses (progressive json) with AI tool calls in production. It’s become a thing, even beyond RSCs, and has many practical uses if you stare at the client and server long enough.

Can you offer some detail into why you find this approach useful?

From an outsider's perspective, if you're sending around JSON documents so big that it takes so long to parse them to the point reordering the content has any measurable impact on performance, this sounds an awful lot like you are batching too much data when you should be progressively fetching child resources in separate requests, or even implementing some sort of pagination.

Re: Progressive JSON

#82

Post by motorest »

onion2k wrote: post #79
hyfgfh wrote: post #71

The thing I have seem in performance is people trying to shave ms loading a page, while they fetch several mbs and do complex operations in the FE, when in the reality writing a BFF, improving the architecture and leaner APIs would be a more productive solution. We tried to do that with GraphQL, http2,... And arguably failed. Until we can properly evolve web standards we won't be able to fix the main issue. Novel fra…

Doesn't that depend on what you mean by "shave ms loading a page"? If you're optimizing for time to first render, or time to visually complete, then you need to render the page using as little logic as possible - sending an empty skeleton that then gets hydrated with user data over APIs is fastest for a user's perception of loading speed. If you want to speed up time to first input or time to interactive you need to…

> If you're optimizing for time to first render, or time to visually complete, then you need to render the page using as little logic as possible - sending an empty skeleton that then gets hydrated with user data over APIs is fastest for a user's perception of loading speed.

I think that OP's point is that these optimization strategies are completely missing the elephant in the room. Meaning, sending multi-MB payloads creates the problem, and shaving a few ms here and there with more complexity while not looking at the performance impact of having to handle multi-MB payloads doesn't seem to be an effective way to tackle the problem.

Re: Progressive JSON

#83

Post by kenanfyi »

jatins wrote: post #77

I have seen Dan's "2 computers" talk and read some of his recent posts trying to explore RSC and their benefits. Dan is one of the best explainers in React ecosystem but IMO if one has to work this hard to sell/explain a tech there's 2 possibilities 1/ there is no real need of tech 2/ it's a flawed abstraction #2 seems somewhat true because most frontend devs I know still don't "get" RSC. Vercel has been aggressively…

I find your analysis very good and agree on why companies like Vercel are pushing hard on RSC.

Re: Progressive JSON

#84

Post by motorest »

xtajv wrote: post #73
Velorivox wrote: post #12

99.9999%* of apps don't need anything nearly as 'fancy' as this, if resolving breadth-first is critical they can just make multiple calls (which can have very little overhead depending on how you do it). * I made it up - and by extension, the status quo is 'correct'.

There's nothing wrong with "accidentally-overengineering" in the sense of having off-the-shelf options that are actually nice. There is something wrong with adding a "fancy" feature to an off-the-shelf option, if said "fancy" feature is realistically "a complicated engineering question, for which we can offer a leaky abstraction that will ultimately trip up anybody who doesn't have the actual mechanics in mind when u…

> There's nothing wrong with "accidentally-overengineering" in the sense of having off-the-shelf options that are actually nice.

Your comment focuses on desired outcomes (i.e., "nice" things), but fails to acknowledge the reality of tradeoffs. Over engineering a solution always creates problems. Systems become harder to reason with, harder to maintain, harder to troubleshoot. For example, in JSON arrays are ordered lists. If you onboard an overengineered tool that arbitrarily reorders elements in a JSON array, things can break in non-trivial ways. And they often do.

Re: Progressive JSON

#85

Post by motorest »

harrall wrote: post #64

I don’t think progressive loading is innovative. What is innovative trying to build a framework that does it for you. Progressive loading is easy, but figuring out which items to progressively load and in which order without asking the developer/user to do much extra config is hard.

> Progressive loading is easy, but figuring out which items to progressively load and in which order without asking the developer/user to do much extra config is hard.

Do developers even control the order in which stuff is loaded? Tha depends on factors beyond a developer's control, such as the user's network speed, the origin server's response speed, which resources are already cached, how much data each request fetches for user A or user B, etc.

Re: Progressive JSON

#86

Post by krzat »

goranmoomin wrote: post #29

Seems like some people here are taking this post literally, as in the author (Dan Abramov) is proposing a format called Progressive JSON — it is not. This is more of a post on explaining the idea of React Server Components where they represent component trees as javascript objects, and then stream them on the wire with a format similar to the blog post (with similar features, though AFAIK it’s bundler/framework speci…

Am I the only person that dislikes progressive loading? Especially if it involves content jumping around.

And the most annoying antipattern is showing empty state UI during loading phase.

Re: Progressive JSON

#87

Post by sriku »

Would a stream where each entry is a list of kv-pairs work just as well? The parser is then expected to apply the kv pairs to the single json object as it is receiving them. The key would describe a json path in the tree - like 'a.b[3].c'.

Re: Progressive JSON

#88

Post by foo42 »

kenanfyi wrote: post #83
jatins wrote: post #77

I have seen Dan's "2 computers" talk and read some of his recent posts trying to explore RSC and their benefits. Dan is one of the best explainers in React ecosystem but IMO if one has to work this hard to sell/explain a tech there's 2 possibilities 1/ there is no real need of tech 2/ it's a flawed abstraction #2 seems somewhat true because most frontend devs I know still don't "get" RSC. Vercel has been aggressively…

I find your analysis very good and agree on why companies like Vercel are pushing hard on RSC.

[flagged]
Post reply on HN