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

111–120 of 244 posts

Re: Progressive JSON

#111

Post by danabramov »

Garlef wrote: post #94
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 think there's a world where you would use the code structuring of RSCs to compile a static page that's broken down into small chunks of html, css, js. Basically: If you replace the "$1" placeholders from the article with URIs you wouldn't need a server. (In most cases you don't need fully dynamic SSR) The big downside is that you'd need a good pipeline to also have fast builds/updates in case of content changes: Pa…

RSC is perfectly capable of being run at the build-time, which is the default. So that’s not too far from what you’re describing.

Re: Progressive JSON

#112

Post by MrJohz »

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…

> sending an empty skeleton that then gets hydrated with user data over APIs is fastest for a user's perception of loading speed

This is often repeated, but my own experience is the opposite: when I see a bunch of skeleton loaders on a page, I generally expect to be in for a bad experience, because the site is probably going to be slow and janky and cause problems. And the more the of the site is being skeleton-loaded, the more my spirits worsen.

My guess is that FCP has become the victim of Goodhart's Law — more sites are trying to optimise FCP (which means that _something_ needs to be on the screens ASAP, even if it's useless) without optimising for the UX experience. Which means delaying rendering more and adding more round-trips so that content can be loaded later on rather than up-front. That produces sites that have worse experiences (more loading, more complexity), even though the metric says the experience should be improving.

Re: Progressive JSON

#113

Post by elcomet »

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…

Too many acronyms, what's FE, BFF?

Re: Progressive JSON

#114

Post by metalrain »

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…

While RSC as technology is interesting, I don't think it makes much sense in practice.

I don't want to have a fleet of Node/Bun backend servers that have to render complex components. I'd rather have static pages and/or React SPA with Go API server.

You get similar result with much smaller resources.

Re: Progressive JSON

#115

Post by danabramov »

tough wrote: post #61
danabramov wrote: post #36

Earlier quoted context omitted.

Yup! To be fair, I also don't mind if people take the described ideas and do something else with them. I wanted to describe RSC's take on data serialization without it seeming too React-specific because the ideas are actually more general. I'd love if more ideas I saw in RSC made it to other technologies.

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.

Re: Progressive JSON

#116

Post by [deleted] »

turtlebits wrote: post #40

Progressive JPEG make sense, because it's a media file and by nature is large. Text/HTML on the other hand, not so much. Seems like a self-inflicted solution where JS bundles are giant and now we're creating more complexity by streaming it.

[deleted]

Re: Progressive JSON

#117

Post by danabramov »

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.

Re: Progressive JSON

#118

Post by rk06 »

tarasglek wrote: post #101

People put so much effort into streaming Json parsing whereas we have a format called Yaml which takes up less characters on the wire and happens to work incrementally out of the box meaning that you can reparse the stream as it's coming in without having to actually do any incremental parsing

Yaml makes json appear user friendly by comparison.

Last thing one want in a wire format is white space sensitivity and ambiguous syntax. Besides, if you are really transferring that much json data, there are ways to achieve it that solves the issues

Re: Progressive JSON

#119

Post by throwingrocks »

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…

> 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

There’s of course a third option: the solution justifies the complexity. Some problems are hard to solve, and the solutions require new intuition.

It’s easy to say that, but it’s also easy to say it should be easier to understand.

I’m waiting to see how this plays out.

Re: Progressive JSON

#120

Post by inglor »

I am not sure the wheel can be rediscovered many more times but definitely check out Kris's work from around 2010-2012 around q-connection and streaming/rpc of chunks of data. Promises themselves have roots in this and there are better formats for this.

Check our mark miller's E stuff and thesis - this stuff goes all the way back to the 80s.

Post reply on HN