Live data from Hacker News

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

mux.com

171–180 of 540 posts

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

#171
> Slow database call? No need to wait; we’ll just send that slow component to the client when it’s ready. Your users can enjoy the rest of the site in the meantime

Seems like he buried the leed, or presumed everyone already knows:

RSCs are ideal when you're pulling data from multiple APIs, some of which may be slower than others.

That said, if the slower one or two are at the top of the page - or at an anchor that might be directly linked to then the UX doesn't really improve, does it?

I'm confused how / why their docs would require React-iviness. Sure perhaps there's a video here or there but is that grounds for tearing down the docs just to use RSCs?

These tools are great, *when they are the right tool for the job*, else we just seem to be reliving an unhealthy infatuation with shiny new object for the sake of my shiny new object is shinier than yours.

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

#172
post #106

Earlier quoted context omitted.

I thought we had lost that technology.

Every CPU in the whole must regenerate websites from json descriptors. That's how it should always have been.

Why did we abandon XSLT?

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

#174

I get the impression that React is trying hard to catch up with the more modern, easier, faster and cheaper alternatives. But instead of fixing the root problems (rerendering and often required memoization, leaky abstractions) and make React easier, it becomes more complex. If the end result was great, I would understand all the effort. But it isn't. React is even slower in real world than the benchmarks show. Next i…

They can't. The ecosystem has too many dependencies that break at this point. Consider that Target.com, Walmart.com, Microsoft Teams, and untold masses of sites are React. The huge component ecosystem. Entire companies built around it. The core concept is broken§, but fixing it means possibly breaking everything else. If you're going to break everything, might as well use something else. All we can do is truck along…

Basically avoiding the mistake Angular made (moving from 1.x to 2+)

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

#175
post #132

Earlier quoted context omitted.

You literally just run: > npx create-next-app@latest Press Enter a few times for default settings and voila, you have a hello world app up and ready to run.

Just because it’s a one liner to install something doesn’t mean you aren’t installing a big, complex, over-engineered thing.

Sure, but if you want to use React to build a Hello World app, the framework is not the one I would blame for overengineering.

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

#176

Earlier quoted context omitted.

F5ing to refresh is a heavier workflow than the hot-reload/refresh you get with every modern web framework.

For sure. Ever had to debug a bug deep inside of a webpage's code that relied on 5-10 preconditions to get it to appear? Without HMR, you're spending a lot of time F5ing and navigating to reproduce/fix it.

If only there was a way to programmatically reproduce the conditions under which the problem appears and then exercise the behaviour that triggers the bug. Then some code could verify whether the problem still appears. Once the problem is fixed this same “test” dark magic could help ensure the problem does not occur again.

Pipe dreams, my friends. Pipe dreams.

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

#177
post #154

Earlier quoted context omitted.

Well they don't look like they were created to manage complexity either, so exactly why are they used?

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.

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

#178
post #131

Earlier quoted context omitted.

> For a simple web hello world you need a huge build and compile pipeline. These frameworks were not created to solve “Simple hello world” apps.

Well they don't look like they were created to manage complexity either, so exactly why are they used?

They were created to manage complexity of building web applications. So something more like Excel than something like dummy photos gallery.

One still can simply drop html file and sprinkle it with jQuery.

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

#179
post #55

What I love about this is how PHP and JavaScript had basically the same syntax (minus a $ symbol here or a var keyword there), and then NodeJS was like, but we want to run JS on the server! And now, 15 years later JavaScript has finally caught up and it’s basically the same as PHP, but with more acronyms and a steeper learning curve (to be fair, streaming data from server to client components using suspense is cool).…

People often ignore that the browsers themselves have also vastly improved. It's what makes a lot of the modern advances possible in the first place.

It's less full-circle, and more a blob that vaguely resembles a circle when you use are fully zoomed out.

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

#180
post #55

What I love about this is how PHP and JavaScript had basically the same syntax (minus a $ symbol here or a var keyword there), and then NodeJS was like, but we want to run JS on the server! And now, 15 years later JavaScript has finally caught up and it’s basically the same as PHP, but with more acronyms and a steeper learning curve (to be fair, streaming data from server to client components using suspense is cool).…

Well, PHP has no client-side rendering, so it's a weird comparison

PHP has as much client-side rendering as React SSR does.

I think the sleight of hand that is happening right now, and that gets people a little confused, is that React is shaping up to be this thing that handles both front and the backend where other solutions can't do that. Sure – but it does that by overloading and complicating what React once was (neither of which per-se negative, I think it's just an apt description of what is going on)

Where other solutions might have abstracted the frontend part into a thing with a different name (or not bother doing it at all) React chooses in a rather unprecedented move to call it all just... React (well, there's Remix and such, but alas). Which is fine, as long as you understand that this new "React" will now probably lead to "React Frontend Dev" and "React Backend Dev", because the work and the complexities that these rolls entail did not just disappear by rolling it into the same name.

It's not entirely clear if architecturally there are going to be more benefits than footguns, but I think it's cool that they are trying.

Post reply on HN