51–60 of 62 posts
I must be getting older, because "everything old is new again" keeps coming to mind. Only advice would be: don't follow these fads unless you a) are doing it to learn or b) can quantify tangible business value in the change. The worst reason to do it is because everyone else seems to be doing it* *Unless literally everyone is doing it and the "old" thing becomes unsupported.
Just curious, what’s the fad you’re referring to. React? Client side rendering? Single page apps?
Earlier quoted context omitted.
See this: https://news.ycombinator.com/item?id=37608452
It seems as though you’re reading this article—and apparently others on the topic—as some form of attention metric gaming combat. I think the author just, uh… wrote an article about their experience with adopting a technology. You clearly have familiarity with the technical landscape, perhaps more than most here! And maybe I’m projecting this part, but my hunch is that (like me) you follow the space closely? If I may…
If anything I'm helping people less experienced understand this. HN does this title clarification all the time for much less concrete things.
I'd ask you why you felt necessary to bring in the "weird" adjective when clearly you understand this area and exactly how the less informed may not understand those graphs and title - in this very thread many of people even seem totally confused that RSC = the only way to do server rendering = novel to React. If I can give you feedback as well, instead of trying to score a point and muddy waters, just write the improved version of what I'm saying if you feel capable of doing so.
Earlier quoted context omitted.
> Couple with sending some static parts that avoid JS which is quite doable If when you say "they could have moved to a server based app", you are implying that they could have done partial hydration easily some other way, that's a wild assumption. Until very recently partial hydration was not even on the table, as the community decided that downloading 10MB of JS for every website was fine, and not 'quite doable' fo…
> and not 'quite doable' for the majority of React apps The article is about a mostly-static marketing page.
Earlier quoted context omitted.
> Couple with sending some static parts that avoid JS which is quite doable If when you say "they could have moved to a server based app", you are implying that they could have done partial hydration easily some other way, that's a wild assumption. Until very recently partial hydration was not even on the table, as the community decided that downloading 10MB of JS for every website was fine, and not 'quite doable' fo…
> and not 'quite doable' for the majority of React apps The article is about a mostly-static marketing page.
Earlier quoted context omitted.
It seems as though you’re reading this article—and apparently others on the topic—as some form of attention metric gaming combat. I think the author just, uh… wrote an article about their experience with adopting a technology. You clearly have familiarity with the technical landscape, perhaps more than most here! And maybe I’m projecting this part, but my hunch is that (like me) you follow the space closely? If I may…
I feel like my comments are fine and curious who you think I'm not giving grace to, I'm not attacking anyone except the article framing itself. My only ask was that HN, which usually clarifies titles to be more accurate avoid extra hype, apply that here, as the company obviously profits at the expense of the uninformed with the title here. If anything I'm helping people less experienced understand this. HN does this…
Not trying to score anything, I just sincerely think your approach to the article and its discussion is unnecessarily combative.
> just write the improved version of what I'm saying if you feel capable of doing so.
I don’t agree with your perspective that there’s anything deceptive or untoward about the article—or its title—as presented. I don’t feel capable of rewriting that position. Cheers!
Earlier quoted context omitted.
I feel like my comments are fine and curious who you think I'm not giving grace to, I'm not attacking anyone except the article framing itself. My only ask was that HN, which usually clarifies titles to be more accurate avoid extra hype, apply that here, as the company obviously profits at the expense of the uninformed with the title here. If anything I'm helping people less experienced understand this. HN does this…
> If I can give you feedback as well, instead of trying to score a point and muddy waters Not trying to score anything, I just sincerely think your approach to the article and its discussion is unnecessarily combative. > just write the improved version of what I'm saying if you feel capable of doing so. I don’t agree with your perspective that there’s anything deceptive or untoward about the article—or its title—as p…
Earlier quoted context omitted.
> If I can give you feedback as well, instead of trying to score a point and muddy waters Not trying to score anything, I just sincerely think your approach to the article and its discussion is unnecessarily combative. > just write the improved version of what I'm saying if you feel capable of doing so. I don’t agree with your perspective that there’s anything deceptive or untoward about the article—or its title—as p…
I guess the three people who confused it in this very thread were just wrong to be confused.
Earlier quoted context omitted.
> Couple with sending some static parts that avoid JS which is quite doable If when you say "they could have moved to a server based app", you are implying that they could have done partial hydration easily some other way, that's a wild assumption. Until very recently partial hydration was not even on the table, as the community decided that downloading 10MB of JS for every website was fine, and not 'quite doable' fo…
Totally agree that partial hydration helps more than full hydration, but note that if you compared SSR vs RSC the charts they posted wouldn't look so impressive. Maybe I was too strong worded, but the point stands that without making it really clear they are "skipping a generation" basically, it makes their comparison look extremely favorable, whereas RSC actually has a big overhead: it serializes all props and the e…
That's what the article is about, isn't it? The gain comes from going from client-only to server-rendered. They did this using RSC. You could also do it using handlebars and jQuery if it was 2010 (with probably 100x better performance).
> if you had compared SSR vs RSC you'd see that the numbers don't actually improve so much
From the article: We saw a whopping 62% reduction in bundle size as well as as 63% improvement in Google's Speed Index. You would not get those gains by simply enabling SSR in an existing app, as the bundle size will remain the same. Unless.. you use Astro or RSC to enable SSR with partial hydration. Which is what they did.
Earlier quoted context omitted.
> Couple with sending some static parts that avoid JS which is quite doable If when you say "they could have moved to a server based app", you are implying that they could have done partial hydration easily some other way, that's a wild assumption. Until very recently partial hydration was not even on the table, as the community decided that downloading 10MB of JS for every website was fine, and not 'quite doable' fo…
> and not 'quite doable' for the majority of React apps The article is about a mostly-static marketing page.
Earlier quoted context omitted.
I guess the three people who confused it in this very thread were just wrong to be confused.
I can’t stop you from continuing to engage combatively, but I’ll ask you to kindly stop doing so with me. Thanks.
If you wish to engage substantively, do see the multiple confused people in this very thread that illustrate the point clearly. It's very hard to reconcile their confusion with your point that this is clear to the general audience.
Perhaps your very experience with the subject is a hindrance to seeing that. Cheers.