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

11–20 of 540 posts

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

#11

Post by Osiris »

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 update the UI), I can’t believe we’re going back that way, but with wildly more complicated patterns than we had before.

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

#12

Post by mediumsmart »

In server-side rendering, clients are sent HTML that they can see immediately

I noticed this too. You can put a plaintext file on the server and it gets transferred to the browser pretty fast. You can also put another plaintext file ending with .css on the server and it can make things on the first page move and look really nice just because the browser knows what to do with it.

It’s a neat trick but still second to useful content on the first page (that is the page you get to read, if it lets you).

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

#13

Post by sam0x17 »

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…

Yeah, I've witnessed the entire arc also as an ex-ex-ex PHP developer from the early 00s, and I literally recall the original justification for this whole exodus that lead to the creation of React and a slew of other things was "jquery bad".

I just wish we had skipped all the in-between stuff and just arrived at htmx back in 2011 instead of now. Maybe I'd still be doing frontend stuff and not burying my head as far into backend as humanly possible while I wait for a workflow that doesn't require a package.json and a 3 GB node_modules folder so I can make the same frontend widget I could make with 50 lines of js in 2007.

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

#16

Post by ytoawwhra92 »

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

Yeah, I've witnessed the entire arc also as an ex-ex-ex PHP developer from the early 00s, and I literally recall the original justification for this whole exodus that lead to the creation of React and a slew of other things was "jquery bad". I just wish we had skipped all the in-between stuff and just arrived at htmx back in 2011 instead of now. Maybe I'd still be doing frontend stuff and not burying my head as far i…

> I just wish we had skipped all the in-between stuff and just arrived at htmx back in 2011 instead of now.

We kind of did (well, 2013), but it just wasn't backed by a massive developer marketing effort.

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

#18

Post by quickthrower2 »

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…

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).

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

#19

Post by quickthrower2 »

CipherThrowaway wrote: post #4
swyx wrote: post #2

https://docs.mux.com/ doesnt seem very interactive at all. i guess i'm being that guy but i'm wondering why it had to be in React, much less RSCs.

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.

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

#20

Post by onion2k »

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 wait for things. The page just doesn't render until it has the data it needs.

- 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.

I'm of the opinion that SSR is a better alternative to a bad SPA, but marginally worse than a good SPA, so for most teams it's a good approach because building a good SPA is hard. If people want to use SSR and that results in me not seeing 4MB homepages any more that can only be considered a win.

Post reply on HN