Live data from Hacker News

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

mux.com

341–350 of 540 posts

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

#341
post #93

Doesn’t make any sense for me why we are now using React in the backend, to render HTML… Let’s go back to 10 years ago.

Reacts programming model appeals to people, and react is good at problems that have a predictable output like HTML. Plus if your frontend is react, it’s much easier to keep all the html generation in one place.

A combination of the devil you know and Stockholm Syndrome.

It was better in many ways than the dominant techniques in 2013, sure, but that's not a terribly high bar, especially when observing the React model a decade later.

React served well enough for quick starts. It proved… challenging… for ongoing maintenance and quality control in long-lived projects.

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

#342
post #172

Earlier quoted context omitted.

Why did we abandon XSLT?

XSLT still works in browsers believe it or not. It's great for making templated static sites.

I find XML quite readable but XSL's mix of logic expressed in XML and XML content is just awful. Syntax highlighting does help somewhat though.

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

#343

Earlier quoted context omitted.

You utter these heresies whilst holding 10k files each containing 10 demonic incantations. Let us not sink into unproductive musings of the intellect, but meditate on the nature of the pendulum swing.

My ducks are in the row and there is no pendulum swing. There is one only in people's heads. People who didn't learn the tools then (when JS era started) and are refusing to learn them now (when more and more focus is on SSR). These people's opinions are irrelevant as their only argument is that they didn't invest the time to understand the benefits.

[deleted]

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

#344
post #130

Earlier quoted context omitted.

React is as baked in now as Java and Covid.

A little over 10 years ago we were saying this about jQuery. React definitely solves problems that jQuery just couldn't solve well. I know that there are issues in react we still need to address, so I know it will be a matter of time before some new way is developed that will supplant react and we will talk of react then as we talk of jQuery today.

> we will talk of react then as we talk of jQuery today.

That it's still in active development with tons of users?

https://blog.jquery.com/2023/08/28/jquery-3-7-1-released-rel...

God, I hope not.

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

#345

Earlier quoted context omitted.

htmx has been getting tons of attention recently

HTMX is cool, but it's honestly only in the conversation because the developer has leveraged memes and garnered popularity on Twitter.

yeah, i'm not google of facebook or ny times or whatever, i'm a lone dev in montana

what other options did i have?

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

#346

Earlier quoted context omitted.

I can offer suggestions on code-splitting, but bundler memory consumption gets into the weeds quickly.

Yeah we all collectively had a look at it and there's not a lot of solutions available. The bundler needs to bundle everything at some point and you are going to pay the SPA tax. That's why I personally don't recommend SPAs, it introduce a whole other class of issues on top of what you usually deal with. Google makes it work with Gmail and Youtube but it's Google, they can throw infinite engineers at any problem and…

I agree there is a complexity cost for bundlers. Whether to pay it is an equation that roughly aligns with how robust and interactive your client offering needs to be. Applications probably, websites probably not.

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

#347

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…

The problem is that browsers started out as hypertext clients and unwittingly evolved into application platforms to implement, among other things, custom hypertext clients in it. Somehow “lets add more features to make hypertext more capable” turned into “you’re on your own now to implement a usable application with this big incoherent pile of impedance-mismatched features”.

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

#348

Earlier quoted context omitted.

I just ssh to the server and edit the code there, I never understood why people need to have two whole environments that they keep in sync. (though seriously, in my dorm room in the 90s, my pentium 90 desktop at the end of my bed had a fixed IP address and was the server...)

Now add 5 people doing that at the same time and report back on how scaleable that solution is.

You need Kubernetes for a product which has a 5 people team?

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

#349

Earlier quoted context omitted.

My brother just started learning web development this past year and his mind was blown when I told him you could send HTml over HTtp.

I slapped my forehead when I was reading a thread about HTMX and someone asked. "How can you send HTML to the browser without JavaScript?"

It's not React's fault but the ignorance of the average React dev never stops surprising me. From using divs for buttons or links to this.

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

#350
post #130

Earlier quoted context omitted.

A little over 10 years ago we were saying this about jQuery. React definitely solves problems that jQuery just couldn't solve well. I know that there are issues in react we still need to address, so I know it will be a matter of time before some new way is developed that will supplant react and we will talk of react then as we talk of jQuery today.

React is orders of magnitude more embedded than jQuery ever was. On top of that, the breadth and depth of its complexity and ecosystem and the solutions it helped build means it's really not going away in a hurry. Updating a 2013 site from jQuery to Angular was small potatoes compared to updating a site now from react to react2.

Embedded? I would have used the term "infectious".

Its complexity and ecosystem will be its Achilles Heel. There are no small number of examples of folks rewriting their React apps in weeks or even a weekend in something like Svelte. SolidJS is "close enough" in code patterns that folks will be very tempted to jump ship. Vue now has a JSX option.

But here's the kicker: frameworks like Svelte don't need wrappers around vanilla JS libraries like React has. It can use them, but it doesn't need them like React does due React's VDOM and execution model.

In 2012, jQuery and jQuery plug-ins were everywhere and necessary. YUI was dead/dying. Mootools and PrototypeJS were already quite dead. That inertia couldn't stop React despite the rewrites.

Because let's face it. We love rewriting front ends, and every rewrite erases the past. No one's gonna choose a rewrite in React if they have any notion of the alternatives.

Post reply on HN