Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

mux.com

Post reply on HN
Print view View original

21–30 of 540 posts

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

#21

Post by sam0x17 »

quickthrower2 wrote: post #18
Osiris wrote: post #11

Earlier quoted context omitted.

I also am baffled by the return to server side rendering as the new thing. It’s like people forgot that’s how it used to be. I’m sure they’ll claim it’s different now because… hydration or something or another. As a former PHP developer who spent a lot of time both working on server rendered pages and converting server rendered pages to be API/JS (render the core in HTML+JS and use APIs with two way data binding to u…

SSR is different I think because it can perform better, but given the state of most sites on the internet I think 2003 style rails is sufficient for most sites. And I haven’t met a JS-ey UI I have enjoyed using as much as a vanilla HTML one for most online stuff (drawing, games, 3D etc. excepted).

And turbolinks on modern rails apps literally feels like those fancy JS-ey UIs anyway in terms of responsiveness. Not to mention things like phoenix liveview..

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

#22

Post by Cannabat »

chrisco255 wrote: post #9

"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…

Most judgements I've read online of CSR vs SSR miss that distinction of website and web-based application.

Clearly if your website essentially just retrieves some data and displays it to the user, you can use SSR. It seems most frontend discussion - and even most of the frontend dev velocity - focuses on this context.

Other common advice is "you don't need global state mgmt - use component state and a query library with good caching". Nigh impossible to retain performance and high interactivity without redux/mobx/etc.

It's very empowering to be able to create sophisticated web apps that run on any device with a web browser! SPA is a very valuable pattern.

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

#23

Post by uxcolumbo »

Stupid question… why roll your own solution for a marketing site and doc site?

Why not use already battle-tested CMS solutions (opensource or paid) and focus your dev effort on your actual product, in this case a video platform product.

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

#25

Post by iaaan »

chrisco255 wrote: post #9

"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…

I agree. I feel like in my decade or so of professional experience, server-side rendering has made sense a handful of times and client-side rendering has made sense a handful of times. As you're saying: each tool comes with its own strengths and weaknesses and you should really just aim to understand the use case for each so you know when to apply them, rather than look for some one-sentence dogma about which thing is the devil to recite back to yourself when presented with a choice.

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

#26

Post by CipherThrowaway »

quickthrower2 wrote: post #19
CipherThrowaway wrote: post #4

Earlier quoted context omitted.

It seems most of the content is dynamically rendered (at build time with SSG). What alternative did you have in mind?

http://motherfuckingwebsite.com/ styling is sufficient for technical docs. I hate the scroll hijacking and other shenanigans on modern docs sites.

I agree re: scroll hijacking and with a preference for minimal styling, while noting that the styling on docs.mux.com is pretty minimal compared to other docs sites.

What I'm wondering is what the anti-React folks are recommending for generating HTML and/or DOM itself in the docs use case, since most of it needs to be dynamically generated from OpenAPI definitions.

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

#28

Post by gausswho »

onion2k wrote: post #20
chrisco255 wrote: post #9

"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…

The first argument leads to waiting to see anything vs at least seeing something. Many use cases the latter is preferable.

The second case is a common misconception of modern SPA. Code-splitting has been around for a while now. When split across routes it's trivial to implement.

Post reply on HN