nah, I got enough with TCP
Progressive JSON
171–180 of 244 posts
Re: Progressive JSON
#172Earlier quoted context omitted.
It’s not an exact analogy but streaming outside-in (with gradually more and more concrete visual loading states) rather than top-down feels similar to a progressive image to me.
It's data (JPEG/JSON) VS software (HTML/CSS/JS)... you can choose to look at HTML/CSS/JS as just some chunks of data, or you can look at it as a serialized program that wants to be executed with optimal performance. Your blog post makes it seem like your focus is on the latter (and it's just quite typical for react applications to fetch their content dynamically via JSON), and that's where your analogy to the progres…
I used this analogy more from the user's perspective (as a user, a gradually sharpening image feels similar to a website with glimmers gradually getting replaced by revealing content). I don't actually know how JPEG is served under the hood (and the spec is too dense for me) so maybe if you explain the point a bit closer I'll be able to follow. I do believe you that the analogy doesn't go all the way.
RSC streams outside-in because that's the general shape of the UI — yes, you might want to prioritize the video, but you have to display the shell around that video first. So "outside-in" is just that common sense — the shell goes first. Other than that, the server will prioritize whatever's ready to be written to the stream — if we're not blocked on IO, we're writing.
The client does some selective prioritization on its own as it receives stuff (e.g. as it loads JS, it will prioritize hydrating the part of the page that you're trying to interact with).
Re: Progressive JSON
#173Earlier quoted context omitted.
> 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…
> 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
I'm not the creator of React (that would be Jordan). I've also never taken any money from Vercel and I don't care about it. I do think RSC is an interesting technology and I like writing about it while I'm on my sabbatical.
Re: Progressive JSON
#174Earlier quoted context omitted.
> 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…
There’s more to it than size, the framework itself and its execution speed and behaviors. Look at a flame graph of any decent React app for example. Sure, I could’ve been clearer, but you did forget react-dom. And good luck getting RSC going on GH pages.
RSC is perfectly capable of producing static sites. My site is hosted for free on Cloudflare with their static free plan.
Re: Progressive JSON
#175Here's a random, crazy idea:
What if instead of streaming JSON, we streamed CSV line by line? That'd theoretically make it way easier to figure out what byte to stream from and then parse the CSV data into something usable... like a Javascript object.
Re: Progressive JSON
#176This is outside my realm of experience, isn't this kind part of the utility of a triple-store? Isn't that the canonical way to flatten trees data to a streamable sequence?
I think you'd also need to have some priority mechanism for which order to send your triple store entries (so you get the same "breadth first" effect) .. and correctly handle missing entries.. but that's the data structure that comes to mind to build off of
Re: Progressive JSON
#177Earlier quoted context omitted.
There’s more to it than size, the framework itself and its execution speed and behaviors. Look at a flame graph of any decent React app for example. Sure, I could’ve been clearer, but you did forget react-dom. And good luck getting RSC going on GH pages.
RSC is perfectly capable of producing static sites. My site is hosted for free on Cloudflare with their static free plan.
That’s not what I said though. You can generate a static site using spring in Java too, doesn’t mean it actually runs Java.
Re: Progressive JSON
#178Earlier quoted context omitted.
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.
Yea, and also to clarify by "UI", I don't necessarily mean HTML — it could be your own React components and their props. In idiomatic React, you generally don't have these kinds of "global" relations between things anyway. (They could appear inside components but then presumably they'd be bound by matching IDs.)
Re: Progressive JSON
#179This is an interesting idea. I solved this problem in a different way by loading each resource/JSON individually, using foreign keys to link them on the front end. This can add latency/delays with deeply nested child resources but it was not a problem for any of the use cases I came across (pages/screens rarely display parent/child resources connected by more than 3 hops; and if they do, they almost never need them to be loaded all at once).
But anyway this is a different custom framework which follows the principle of resource atomicity and a totally different direction than GraphQL approach which follows the principle of aggregating all the data into a big nested JSON. The big JSON approach is convenient but it's not optimized for this kind of lazy loading flexibility.
IMO, resource atomicity is a superior philosophy. Field-level atomicity is a great way to avoid conflicts when supporting real-time updates. Unfortunately nobody has shown any interest or is even aware of its existence as an alternative.
We are yet to figure out that maybe the real issue with REST is that it's not granular enough (should be field granularity, not whole resource)... Everyone knows HTTP has heavy header overheads, hence you can't load fields individually (there would be too many heavy HTTP requests)... This is not a limitation for WebSockets however... But still, people are clutching onto HTTP; a transfer protocol originally designed for hypertext content, as their data transport.
Re: Progressive JSON
#180Earlier quoted context omitted.
hi dan! really interesting post. do you think a new data serialization format built around easier generation/parseability and that also happened to be streamable because its line based like jsonld could be useful for some?
I don’t know! I think it depends on whether you’re running into any of these problems and have levers to fix them. RSC was specifically designed for that so I was trying to explain its design choices. If you’re building a serializer then I think it’s worth thinking about the format’s characteristics.
I've used React in the past to build some applications and components. Not familiar with RSC.
What immediately comes to mind is using a uniform recursive tree instead, where each node has the same fields. In a funny way that would mimic the DOM if you squint. Each node would encode it's type, id, name, value, parent_id and order for example. The engine in front can now generically put stuff into the right place.
I don't know whether that is feasible here. Just a thought. I've used similar structures in data driven react (and other) applications.
It's also efficient to encode in memory, because you can put this into a flat, compact array. And it fits nicely into SQL dbs as well.