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

41–50 of 540 posts

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

#41

Post by realusername »

gausswho wrote: post #28
onion2k wrote: 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…

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.

That's exactly what my team told me when we transitionned to an SPA. Turns out, splitting properly an SPA is complex and bundling is pretty annoying at the moment.

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

#43

Post by 4hg4ufxhy »

Osiris wrote: post #36
onion2k wrote: 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 still need to do it, but now you additionally have a serialized data format in between client and server. Now you need to keep that format versioned and backwards compatible, otherwise users with cached clients will break.

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

#44

Post by Osiris »

Illotus wrote: post #31

I guess you use what you are familiar with, but using react for doc site instead of using some off the shelf static site generator/cms with caching seems like wasted effort. More fun from dev point of view with react no doubt.

I agree. It’s static content. Why isn’t it just generated as HTML with some JS for the search bar?

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

#45

Post by CipherThrowaway »

Osiris wrote: post #11
sam0x17 wrote: 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 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…

How much experience do you have with RSC and Next.js?

I remember writing PHP and JSF back in the 90s and 00s, and the experience of both writing RSC and Next.js as well as using websites built with these technologies is simply not comparable.

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

#46

Post by Osiris »

CipherThrowaway wrote: post #26
quickthrower2 wrote: post #19

Earlier quoted context omitted.

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.

Static file generation. People are suggesting that tooling creates HTML files from templates at compile time and then served as plain HTML.

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

#47

Post by TheAceOfHearts »

colordrops wrote: post #35
gausswho wrote: post #28

Earlier quoted context omitted.

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.

Or just don't even bundle if you can serve your users with ES6 modules.

Performance with native ESM isn't great since you get cascading requests, unless you have very shallow dependency trees.

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

#48

Post by antoniuschan99 »

Osiris wrote: post #11
sam0x17 wrote: 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 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…

I started in 2010 with Java and JSP and initially thought the same thing. But after reading more about it, I see it as like foldable phones. We’re back to using foldable phones, but it’s totally different than before.

Also, I recall heavily using jQuery and Ajax to update parts of the page before Spa’s came along.

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

#50

Post by mook »

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…

As you say it's very context dependent. Trello makes sense as an SPA because the user stares at the same page all day (the board view), for long stretches at a time, and often requires interaction like dragging cards around. For Google Maps the user spends some time finding the right location, and does a lot of panning. The HR solution my company uses… there the user goes to very distinct pages (time off, goal setting, etc.) and interacts with it by filling in forms. That probably shouldn't be an SPA (but is).

It's considered a bad move to use SPAs because product managers tend to err on writing an app when they should be writing a site; the reverse rarely happens these days.

Post reply on HN