Live data from Hacker News

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

mux.com

71–80 of 540 posts

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

#71
post #36

Earlier quoted context omitted.

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.

We need to do that anyway, our customers call our application through our API. Building our web apps on top of the same ensures that they have the full functionality available, kind of eating our own dog food.

(but yes, we have unusual customers I guess)

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

#72
post #11
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 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.

People want that back, but they also like React, and their existing component libraries, and they want to generate the backend pages with React. It's not that strange.

And you can (I think) pretty seamlessly have part of the page rendered on the server, and parts still function on the client.

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

#73

Earlier quoted context omitted.

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.

Why? I think most modern bundlers and spa routers supports code splitting out of the box by just using dynamic imports, aka: `const myComponent = await import("/path/to/component")`

You still are going to build the whole thing locally anyways, even with vite.js, it takes 2.5GB of RAM on my machine.

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

#74

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

That statement also stood out to me. I suppose the issue was that JS developers cargo cult and started creating everything as a SPA and bootcamps pumped out React developers who only knew how to make SPAs. This generation is now discovering server rendered html through React.

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

#75

Earlier quoted context omitted.

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.

Perhaps I can help? Which bundler? What issues are you encountering?

We're using Vite.js/esbuild, the bundler takes 2.5GB of RAM locally.

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

#76

That seems like a tremendous commitment for such a recent technology.

My thinking as well. Reflects poorly on the company. I'm not in the market for whatever they're doing but if I was my impression is they have a bunch of hipsters drinking coffee and reimplementing stuff no one asked for.

“This technology we heavily rely on is completely changing the way it works. Should we update now and get into the ecosystem?”

“Nah, this guy on hacker news said we’re dumb hipsters for adopting the new normal for react. We should stay on the old versions.”

That’s like saying you don’t trust a company because they updated from PHP 5 to PHP 8.2

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

#77

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…

What is this sorcery you speak of?

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

#78

Earlier quoted context omitted.

Why? I think most modern bundlers and spa routers supports code splitting out of the box by just using dynamic imports, aka: `const myComponent = await import("/path/to/component")`

You still are going to build the whole thing locally anyways, even with vite.js, it takes 2.5GB of RAM on my machine.

I don't understand your concern with it and why this is a problem.

I haven't personally noticed the vite/esbuild memory consumption, but I also run build only once at the end before deployment or generating the prod artifacts.

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

#80

Earlier quoted context omitted.

You still are going to build the whole thing locally anyways, even with vite.js, it takes 2.5GB of RAM on my machine.

I don't understand your concern with it and why this is a problem. I haven't personally noticed the vite/esbuild memory consumption, but I also run build only once at the end before deployment or generating the prod artifacts.

It's a problem because it slows down my machine and each js file which is added makes the ram and cpu problem worse, it just doesn't scale.

We're using typescript so building only once a day isn't an option.

Post reply on HN