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

261–270 of 540 posts

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

#261

Post by throw1234651234 »

bsenftner wrote: post #177
csomar wrote: post #154

Earlier quoted context omitted.

They simplify the on-boarding of 6 months boot-camped front-end developers. They can start working and delivering right away despite not being able to tell the difference between front/back ends and having no understanding of servers.

Exactly! These frameworks enable people with 6 months of "software developer" education to enter the industry and enshitificate our careers with their minimum wage level understanding of actual software engineering, dragging all of us down to their salary level.

I don't really buy this argument. Raw CSS/HTML is easier to understand. At the end of the day, all frameworks really do is remove `getElementById` and a couple helpers like `element.style.display`. This does make code MUCH cleaner, but the argument is that raw code isn't easier to understand.

I have also had a couple of CSS wizards that wrote all the styles by hand - sounds great until someone has to fix it, even a senior designer. In short, a well-used framework that's understood is not necessarily easier, but it does lead to an agreed-on set of abstractions that make things easier to understand. Angular and React are very much there for a reason.

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

#262

Post by swaggyBoatswain »

holoduke wrote: post #125

I think i am getting old. These frameworks are so big and complex. For a simple web hello world you need a huge build and compile pipeline. And now its extended with serverside components. I really wonder what the overhead is. How many of layers of frontend and backend framework code is executed to get the hello world example running. I retreat back to my simple 10kb component framework in which i need only f5 to reb…

This blog post covered SSR better than most blog posts I've seen

Anytime SSR or any of its derivatives comes into the conversation I always ask myself if things are becoming unnecessarily more complex. React server rendered components sounds like it's taking things too far - it goes against the natural developer experience DX order

If your complexity on the app is doubled and it slows and confuses all the developers with increased coding footguns for only a measly gain in performance, is it worth it?

Good old php sites and rails app with no SPAs have worked fine over the years

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

#263

Post by gausswho »

pjc50 wrote: post #60
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.

In practice, the SPA is so slow and the user's device is so much slower than the datacenter that the "something" you see is a useless splash screen, and the actual content takes longer to arrive than just doing it SSR. Reddit is probably the most familiar example of this, because it actually has multiple implementations (old.reddit, i.reddit etc) that let you see the difference!

I am wary of gleaning anything on the matter from Reddit. Their engineering decisions don't fit either the convention nor the needs of most web applications.

As for whether the initial paint is of value, that comes down to product and implementation. Nothing is faster than offline-first or local cache, which SSR does not have a good narraative for.

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

#264

Post by dardarbinks »

brailsafe wrote: post #3

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

Author, here!

It’s a fair question. I think it’s a question I was hoping to address in this article, especially with the incremental migration pattern. If you already have a Next.js site, it’s honestly not too bad. If you’re not on Next.js, well, that’s a big migration either way. But considering server components during that migration might not be unreasonable — you’re writing React components either way, albeit RSC is a more complex mental model.

More specifically though: The docs migration took me about a month-and-change of work. Some of that was moving all of our styling to Tailwind. Some of it was (optional) RSC code gymnastics that I mentioned in the advanced patterns section, to see how many kB we could leave on the server. And much of it was the information architecture changes I talked about in that earlier blog post.

Meanwhile, marketing took us three months, but that number is complicated too, since we were rebranding the site, touching every component and page anyways. Most paths had like, 2 minutes of direct RSC work. Moving the calls to the data layer from outside our components to inside.

IMO not bad. In both cases, we had to work on the whole site, anyways. Might as well creep the scope a bit and move to the new React thing, since it looks like that’s where the puck is going.

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

#265

Post by consoomer »

Am I the only one that believes classic Turbolinks (pre-Turbo) is the ideal solution to SSR? It works out of the box with JS disabled. No extra logic is needed on the server side (as is needed with HTMX). You can still perform partial updates HTMX style if you want (data-remote="true", and wrap response with a script/dom insert).

I am using it in all of my products (non-Rails) and it has been so great.

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

#266

Post by cccybernetic »

throw1234651234 wrote: post #255
asynchronous wrote: post #241

Earlier quoted context omitted.

After kicking and screaming about learning yet another React framework I took the time to build an app fresh in NextJS and it really was a breath of fresh air, felt more like a mature, simpler form of React.

Feels like bloated garbage to me. "Hold on, let me make an MVC React framework with a Node API, so you can call your APIs from another API!". Thanks Next.js. Really wanted this. Honestly, might as well go back to Angular at that point - no redundant "API" there, at least. Also, automagic, automagic everywhere. "Let me just intercept your request and send it to a HANDLER, wow." "Let me just have a magical 'getServerSi…

The API isn't redundant, it's convenient. You don't have to use it. Just delete the /api folder and make your requests either from the client side or fetch the data inside the handler that you're complaining about. With the new app router, you can fetch it from the server component itself without the handler.

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

#268

Post by consoomer »

mediumsmart wrote: post #12

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 next? Are you going to tell me you can send down a text file that runs code on a page by page basis?

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

#269

Post by gausswho »

the8472 wrote: post #113
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.

"at least seeing something" leads to jira or teams where you open a thing and then its entries slowly pop in and shift as they get loaded. An illusion of a site being there that can't be used because you can neither focus on the text nor use any of the inputs as they shift beneath your eyes.

That'd be a poor implementation. CSR can generate immediately interactive forms that don't shift. JIRA and MS are absolutely subpar irregardless of this matter.

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

#270

Post by fidotron »

holoduke wrote: post #125

I think i am getting old. These frameworks are so big and complex. For a simple web hello world you need a huge build and compile pipeline. And now its extended with serverside components. I really wonder what the overhead is. How many of layers of frontend and backend framework code is executed to get the hello world example running. I retreat back to my simple 10kb component framework in which i need only f5 to reb…

This stuff appeals to a breed of management in the same way "full stack development" does, which is to say those in denial of the need or value of specialisation.

The other benefit of such developers is they don't need teamwork. You just throw a feature request out at each dev and they do it end-to-end with you oblivious to the mess that is being created in the process.

Post reply on HN