Live data from Hacker News

Things I wish I knew before moving 50K lines of code to React Server Components

mux.com

61–70 of 540 posts

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#61

"This was called client-side rendering (CSR) or single-page applications (SPA) and was widely considered a bad move." Why was it considered a bad move to go SPA? I generally disagree with this statement. But I feel like whenever this conversation comes up we're talking different applications altogether. A SPA is fine for a back office application. What it's not necessarily good for is a splash page or marketing page…

[deleted]

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#64
post #6

Maybe it's just the circles in which I've been active lately, but I feel like a lot of time and effort is spent these days practically just moving code around between implementations, without much practical change in user experience. What drives this behaviour? I mean the question on a deeper level. An answer like "the technology hype cycle" just begs the question. Why does someone feel like they have to move busines…

[deleted]

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#65
post #36
post #20

Earlier quoted context omitted.

Why was it considered a bad move to go SPA? There are two main advantages of SSR; - API calls necessary to build the page happen in the data center instead of the public internet, so they're much faster. You can use a database query instead of an HTTP API call if you really want to. That results in a huge speed gain for a lot of sites. It also reduces the complexity of the page - devs don't need to build logic to wai…

Doing database lookups on the server was the primary reason people STOPPED doing server side render and shifted to JS+API. Why do we now think that the way we used to do it was actually better?

You've still got to do DB lookups to serve the API, except now your DB traffic has to go through more and longer pipes?

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#66

Not sure if the OP is here but on Firefox clicking the "API reference" button on the top left causes the full page transition to stutter. The profiler says more than 150ms is spent in a getBoundingClientRect call in a componentDidMount triggering reflow + style computation and 30ms on set Element.innerHTML. That seems excessive especially since I'm looking at this on a recent M1 Macbook.

[deleted]

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#67
post #5

At the point of server components I sort of giggle to myself that we've come full circle and maybe I can come out of my SSR bomb shelter and enjoy life again

I think there is a difference this time round and it isn't just to do with where the pages are rendered. There's a yearning for simplicity. In days of yore, "simple" SSR (eg JSP, ASP, etc) came with a selection of "helpful" design patterns and frameworks (Struts, Stripe et al) that all added to the complexity, not reduced it.

Modern SSR implies just do simple rendering on the server and hook it up with simple tools like Htmx, Turbolinks, etc.

Keep the complexity accessible on the outside, like the Pompidou Centre.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#69
post #20

"This was called client-side rendering (CSR) or single-page applications (SPA) and was widely considered a bad move." Why was it considered a bad move to go SPA? I generally disagree with this statement. But I feel like whenever this conversation comes up we're talking different applications altogether. A SPA is fine for a back office application. What it's not necessarily good for is a splash page or marketing page…

Why was it considered a bad move to go SPA? There are two main advantages of SSR; - API calls necessary to build the page happen in the data center instead of the public internet, so they're much faster. You can use a database query instead of an HTTP API call if you really want to. That results in a huge speed gain for a lot of sites. It also reduces the complexity of the page - devs don't need to build logic to wai…

> - You don't send the user code they don't need yet. If someone is viewing a page that doesn't have a widget, but you send them the code for the widget because you've bundled everything the site needs into one JS file, you've wasted the users time and bandwidth. SSR is a very easy way to solve that problem.

Just saying: the generated HTML could be a lot larger than the Javascript generating it. Usually it won't be, but it's not a given that sending the HTML is less bandwidth.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#70
post #6

Maybe it's just the circles in which I've been active lately, but I feel like a lot of time and effort is spent these days practically just moving code around between implementations, without much practical change in user experience. What drives this behaviour? I mean the question on a deeper level. An answer like "the technology hype cycle" just begs the question. Why does someone feel like they have to move busines…

The web browser is both a critical UI technology - it's the only working truly cross platform sandbox - and therefore a battlefield between potential monopolists that has stagnated like a WW1 field of trenches and wire.

Because only the tiniest, most incremental changes can be made to the browsers, and because there are fundamental native/universality conflicts all the time, making tiny improvements to UX requires huge behind the scenes troop movements. And then it's subjective, so maybe it just makes the UX worse in the end.

UI frameworks seem to be surprisingly hard conceptually. Neither Microsoft nor Apple have really proven that they can do better when on a field entirely under their control.

Not to mention business model considerations, such as the worsening of Reddit.

Post reply on HN