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

151–160 of 244 posts

Re: Progressive JSON

#151

Post by andrewingram »

atombender wrote: post #148
andrewingram wrote: post #144

Earlier quoted context omitted.

For the use case of streaming data for UI, I don’t think empty arrays and nulls are sufficient information. At any moment during the stream, you need the ability to tell what data is pending. If pending arrays are just returned as empty arrays, how do I know if it’s empty because it’s actually empty, or empty because it’s pending? GraphQL’s streaming payloads try to get the best of both worlds, at any point in time y…

As I commented in https://news.ycombinator.com/item?id=44150238 , all you need is a way to express what is pending, which can be done using JSON key paths. Of course, you could do it in-band, too: {"comments": {"state": "pending", "values": []}} …at the cost of needing your data model to be explicit about it. But this has the benefit of being diffable, of course, so once the data is available, the diff is just the ne…

Yes, hence the last paragraph in my comment :)

Re: Progressive JSON

#152

Post by MrJohz »

gavinray wrote: post #135
techpression wrote: post #134

Reading this makes me even happier I decided on Phoenix LiveView a while back. React has become a behemoth requiring vendor specific hosting (if you want the bells and whistles) and even a compiler to overcome all the legacy. Most of the time nobody needs this, make sure your database indexes are correct and don’t use some under powered serverless runtime to execute your code and you’ll handle more load than most peo…

> React has become a behemoth requiring vendor specific hosting This is one of the silliest things I've read in a while. React is sub-3kB minified + gzip'ed [0], and the grand majority of React apps I've deployed are served as static assets from a fileserver. My blog runs off of Github Pages, for instance. People will always find a way to invent problems for themselves, but this is a silly example. [0] https://bundle…

I find the Krausest benchmarks[0] to be useful for these sorts of comparisons. There are always flaws in benchmarks, and this one particularly is limited to the performance for DOM manipulation of a relatively simple web application (the minimal VanillaJS implementation is about 50 lines of code). That said, Krausest and the others who work on it do a good job of ensuring the different apps are well-optimised but still idiomatic, and it works well as a test of what the smallest meaningful app might look like for a given framework.

I typically compare Vanilla, Angular, SolidJS, Svelte, Vue Vapor, Vue, and React Hooks, to get a good spread of the major JS frameworks right now. Performance-wise, there are definitely differences, but tbh they're all much of a muchness. React famously does poorly on "swap rows", but also there's plenty of debate about how useful "swap rows" actually is as a benchmark.

But if you scroll further down, you get to the memory allocation and size/FCP sections, and those demonstrate what a behemoth React is in practice. 5-10× larger than SolidJS or Svelte (compressed), and approximately 5× longer FCP scores, alongside a significantly larger runtime memory than any other option.

React is consistently more similar to a full Angular application in most of the benchmarks there than to one of the more lightweight (but equally capable) frameworks in that list. And I'm not even doing a comparison with microframeworks like Mithril or just writing the whole thing in plain JS. And given the point of this article is about shaving off moments from your FCP by delaying rendering, surely it makes sense to look at one of the most significant causes to FCP, namely bundle size?

[0]: https://krausest.github.io/js-framework-benchmark/2025/table...

Re: Progressive JSON

#153

Post by pjungwir »

Does this scheme give a way to progressively load slices of an array? What I want is something like this:

    ["foo", "bar", "$1"]
And then we can consume this by resolving the Promise for $1 and splatting it into the array (sort of). The Promise might resolve to this:

    ["baz", "gar", "$2"]
And so on.

And then a higher level is just iterating the array, and doesn't have to think about the promise. Like a Python generator or Ruby enumerator. I see that Javascript does have async generators, so I guess you'd be using that.

The "sort of" is that you can stream the array contents without literally splatting. The caller doesn't have to reify the whole array, but they could.

EDIT: To this not-really-a-proposal I propose adding a new spread syntax, ["foo", "bar", "...$1"]. Then your progressive JSON layer can just deal with it. That would be awesome.

Re: Progressive JSON

#154

Post by izger »

Interesting idea. Another way to implement the same without breaking json protocol framing is just sent {progressive: "true"} {a:"value"} {b:"value b"} {c: {d}c:"value b"} .. {progressive: "false"}

and have

{ progressive: "false", a:"value", b:"value b", .. }

on top of that add some flavor of message_id, message_no (some other on your taste) and you will have a protocol to consistently update multiple objects at a time.

Re: Progressive JSON

#155

Post by Wazako »

motorest wrote: post #81
vinnymac wrote: post #52

Earlier quoted context omitted.

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…

Slow llm generation. A progressive display of a progressive json is mandatory.

Re: Progressive JSON

#156

Post by richin13 »

tough wrote: post #62
vinnymac wrote: post #52

Earlier quoted context omitted.

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.

how do you do that exactly?

Not the original commenter but I’ve done this too with Pydantic AI (actually the library does it for you). See “Streaming Structured Output” here https://ai.pydantic.dev/output/#streaming-structured-output

Re: Progressive JSON

#157

Post by owebmaster »

gavinray wrote: post #146
owebmaster wrote: post #137

Earlier quoted context omitted.

> This is one of the silliest things I've read in a while. You know that the author of this post is the creator of React and that he's been pushing for RSC/Vercel relentlessly, right? btw reactdom is ~30kb gzipped so React minimal bundle is around 35kb

If you really want to bikeshed over size, you can use Preact which is a genuine 3kB full drop-in for React.

Why would I? React is just bad, the change from classes/function components to hooks abstraction was terrible but the current push to RSC made me quit 2 years ago with zero regrets. Life is great when you don't need to debug zillions of useless components re-render.

Re: Progressive JSON

#158

Post by Existenceblinks »

danabramov wrote: post #117
Existenceblinks wrote: post #103

It's useless as data is not just some graphic semantic, they have relation, business rules on top, not ready to interact with if not all are ready, loaded.

It’s definitely not useless. You’re right that it requires the interpreting layer to be able to handle missing info. The use case at the end of the article is streaming UI. UI, unlike arbitrary data, is actually self-describing — and we have meaningful semantics for incomplete UI (show the closest loading state placeholder). That’s what makes it work, as the article explains in the last section.

Thanks Dan. Yes, I agreed on the ui part, it seems to work in most cases. Some html tags have relation like `` or `[popover]` attribute, but if we make all kind of relations trivial then it's benefit for sure.

Re: Progressive JSON

#159

Post by lioeters »

liamness wrote: post #138
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…

You can of course still just export a static site and host it on a basic CDN, as you say. And you can self host Next.js in the default "dynamic" mode, you just need to be able to run an Express server, which hardly locks you into any particular vendor. Where it gets a little more controversial is if you want to run Next.js in full fat mode, with serverless functions for render paths that can operate on a stale-while-…

> thankfully Next.js / Vercel have proposed to implement (and dogfood) adapters that allow this functionality to be implemented on different platforms with a consistent API:

Seeing efforts like this (started by the main dev of Next.js working at Vercel) convinces me that the Vercel team is honestly trying to be a good steward with their influence on the React ecosystem, and in general being a beneficial community player. Of course as a VC-funded company its purpose is self-serving, but I think they're playing it pretty respectably.

That said, there's no way I'm going to run Next.js as part of a server in production. It's way too fat and complicated. I'll stick with using it as a static site generator, until I replace it with something simpler like Vite and friends.

Re: Progressive JSON

#160

Post by owebmaster »

cluckindan wrote: post #97
owebmaster wrote: post #31

Earlier quoted context omitted.

It can't fall out of favor if it was never really in favor to begin with. GraphQL was a quite brief hype then a big technical debt.

What do you mean by technical debt here?

Everywhere I worked with GraphQL it was always a pain for the backend team to keep the graphql server updated and also a pain to use in the frontend, simple REST apis or JSON-RPC are much better.
Post reply on HN