Live data from Hacker News

Progressive JSON

overreacted.io

131–140 of 244 posts

Re: Progressive JSON

#131

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'.

Multiple calls?! That sounds like n*n+1. Gross :P

I think the issue with the example json is that it's sent in OOP+ORM style (ie nested objects), whereas you could just send it as rows of objects, something like this;

  {
    header: "Welcome to my blog",
    post_content: "This is my article",
    post_comments: [21,29,88], # the numbers are the comment ID's
    footer: "Hope you like it",
    comments: {21: "first", 29: "second", 88: "third" }
  }
But then you may as well just go with protobufs or something, so your endpoints and stuff are all typed and defined, something like this;

  syntax = "proto3";
  service DirectiveAffectsService {
    rpc Get(GetPageWithPostParams) returns (PageWithPost);
  }
  message GetPageWithPostParams {
    string post_id = 1;
  }
  message PageWithPost {
    string page_header = 1;
    string page_footer = 2;
    string post_content = 3;
    repeated string post_comments = 4;
    repeated CommentInPost comments_for_post = 5;
  }
  message CommentInPost {
    string comment_id = 1;
    string comment_text = 2;
  }
And with this style, you don't necessarily need to embed the comments in 1 call like this, and you could cleanly do it in 2 like parent-comment suggests (1 to get page+post, second to get comments), which might be aided with `int32 post_comment_count = 4;` instead (so you can pre-render n blocks).

Re: Progressive JSON

#132
post #76

I've always liked the idea of putting latency requirements in to API specifications. Maybe that could help delimit what is and is not automatically inlined as the author proposes.

Choose APIs that offer SLAs. It's not about being picky. It's about communicating needs, and setting boundaries that are designed to satisfy those needs without overwhelming anybody's system to the point of saturation and degraded performance.

Right, but what if some of that SLA information actually directed the code itself.

In the context of this blog post, what if the SLA was <100ms for an initial response, with some mandatory fields, but then any additional information which happens to be loaded within that 100ms automatically is included. With anything outside the 100ms is automatically sent in a followup message?

Re: Progressive JSON

#133

Earlier quoted context omitted.

Agree with everything you're saying here, but to be fair I think the analogy with Progressive JPEG doesn't sit quite right with your concept. What you're describing sounds more like "semantic-aware streaming" - it's as if a Progressive JPEG would be semantically aware of its blob and load any objects that are in focus first before going after data for things that are out of focus. I think that's a very contemporary p…

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 progressive mode of JPEGs falls a bit flat and "streaming outside-in" doesn't seem like all you want.

Progressively loaded JPEGs just apply some type of "selective refinement" to chunks of data, and for Progressive selective refinement to work it's necessary to "specify the location and size of the region of one or more components prior to the scan"[0][1]. If you don't know what size to allocate, then it's quite difficult(?) to optimize the execution. This doesn't seem like the kind of discussion you'd like to have.

Performance aware web developers are working with semantic awareness of their content in order to make tweaks to the sites loading time. YouTube might prefer videos (or ads) to be loaded before any comments, news sites might prioritize text over any other media, and a good dashboard might prioritize data visualizations before header and sidebar etc.

The position of the nodes in any structured tree tells you very little about the preferred loading priority, wouldn't you agree?

[0] https://jpeg.org/jpeg/workplan.html

[1] https://www.itu.int/ITU-T/recommendations/rec.aspx?id=3381 (see D.2 in the PDF)

EDIT: Btw thanks for your invaluable contributions to react (and redux back then)!

Re: Progressive JSON

#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 people realize.

If you’re Facebook scale you have unique problems, most of us doesn’t.

Re: Progressive JSON

#135

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://bundlephobia.com/package/react@19.1.0

Re: Progressive JSON

#137

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…

> 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

Re: Progressive JSON

#138
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-revalidate basis. Currently it is very hard for anyone other than Vercel to properly implement that (see the opennextjs project for examples), due to undocumented "magic". But 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:

https://github.com/vercel/next.js/discussions/77740

I don't think the push for RSC is at all motivated by the shady reasons you're suggesting. I think it is more about the realisation that there were many good things about the way we used to build websites before SPA frameworks began to dominate. Mostly rendering things on the server, with a little progressive enhancement on the client, is a pattern with a lot of benefits. But even with SSR, you still end up pushing a lot of logic to the client that doesn't necessarily belong there.

Re: Progressive JSON

#139

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…

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.

Re: Progressive JSON

#140

Earlier 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

Dan Abramov isn't "the creator of React", he just became an evangelist for react ever since he got to the team at Facebook through his work on redux. He is pushing for RSC (as that's where react's future seems to be), but what makes you think he's pushing for Vercel?
Post reply on HN