Live data from Hacker News

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

mux.com

381–390 of 540 posts

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

#381

Stop a second before you go into RSCs. Whatever you want to achieve ultimately is much easier/quicker/scalable done in real fullstack (or classic web-) frameworks! Rails/Django/Laravel/… + Turbolinks/Htmx/… or even sprinkle some light clientside JS for fancyness. Or go best-of-all-worlds if you happen to know Elixir/Phoenix. But don’t continue the descent into RSCs, now matter how many people tweet about it. These fo…

>These folks with less than 10y industry experience will run into all the basic problems we had in vanilla PHP sites years ago, I even spotted react components with inline-sql-hooks already. This time with much accidental complexity overhead! So much this. It's like our industry has a rolling 10 year cycle of amnesia. We moved away from server rendered UI for very, very good reasons. Of course the SEO argument is alw…

Pure "content" sites don't need to be SPAs, but web "applications" suck ass rendered server side.

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

#382
I am pretty sure 99% of the development time is no longer spent on solving problems and implementing features, but on creating unnecessary complex systems, deploying and maintaining them in an auto-scalable cloud, when a single $5 VPS would be performant enough, if all that complexity wasn't there. We should spend more time in writing efficient, simple code with fewer dependencies. We get so much natively nowadays that often choosing to add another framework/library adds more limitations than benefits.

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

#383

Earlier quoted context omitted.

>These folks with less than 10y industry experience will run into all the basic problems we had in vanilla PHP sites years ago, I even spotted react components with inline-sql-hooks already. This time with much accidental complexity overhead! So much this. It's like our industry has a rolling 10 year cycle of amnesia. We moved away from server rendered UI for very, very good reasons. Of course the SEO argument is alw…

> We moved away from server rendered UI for very, very good reasons. In some cases, it's clear that it's a webapp and a SPA is warranted. In some cases, it should just have been a website, but yet there were organizational reasons to use react - producing technologically bad results in detriment of the users.

You can have a "static" site that renders react components to non-root nodes in order to provide interactivity if needed.

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

#384

Earlier quoted context omitted.

Be sure not to disturb this apprentice's troubled mind with such highly advanced topics as server side includes and related sorcery. Do not awaken the Ancients for only the pure of heart will survive such an encounter.

Yeah 10 different files with 10k unorganized lines each is totally different :D I swear you js haters never fail to make me laugh with all the ignorant lamentations.

Do these guys actually think you should only write a singular (or maybe even a low plural number of) html file(s)? That’s crazy haha, that’d be pretty rough to maintain!

Could they have been joking that, maybe, there’s a lot of folks who are a little too tunnel visioned on the newest most modern js metaframeworks that they have little or limited knowledge of the foundations of their ecosystem? Given that you know something about html files and basic web servers, was your position necessarily the original subject of the joke/point here? Surely it was! Gruff old school devs are so obstinate and short sighted haha.

You opened, intending to construct an argument on your genuine position, with a massive strawman, on a lighthearted commentary over a line from the article that was purposefully taken slightly out of context- not even remotely a tirade on “js hating.” You’re not having an argument in this comment thread with anyone, because no one was even discussing anything to begin with.

I think there’s things to laugh at here (like the original joke) that aren’t how genuinely stupid you think the commenter who is ironically replying to every of your comments in a vague and mystical tone.

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

#385

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.

Because Vercel wants to host your backend and they have their hands in React

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

#386

Earlier quoted context omitted.

>These folks with less than 10y industry experience will run into all the basic problems we had in vanilla PHP sites years ago, I even spotted react components with inline-sql-hooks already. This time with much accidental complexity overhead! So much this. It's like our industry has a rolling 10 year cycle of amnesia. We moved away from server rendered UI for very, very good reasons. Of course the SEO argument is alw…

"very, very good reasons" bullshit, you do not need to turn landing pages into 30MB react bundles with 20 morbillion node modules

There are definitely use cases where you want a render loop in web, pioneered by React, instead of traditional approaches for a web application. I think the pendulum swung too far and too many sites are being built as a SPA, but there are absolutely some "very good reasons" to build a SPA with React. As always, it depends on the use case.

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

#387

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.

That's how we did it at my first gig with PHP and Drupal. I'm not going to say it was great or even particularly good, but given our work was split across different modules, you could easily have multiple people either uploading changes over FTP or doing some quick hacks over SSH. After all, you only needed to copy over your changes and not re-deploy the entire project. The server was a little Dell box sat under the desk of the 'CTO' in his office.

There were some cowboy-level engineering practices for sure, to the point that I'm not sure you could call it 'software engineering', but there was definitely some beauty in the simplicity of that setup compared to what we typically have to do these days. At least after you set up the box and the access to it, anyway.

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

#388

Earlier quoted context omitted.

I think you just sold me on Svelte, and I am not joking - I haven't tried it yet, but I want to now.

the only downside for me is that there aren't many mature UI libs for it yet. I was evaluating it for a Tauri-based project but I went with React instead because of this.

You guys can try https://bulma.io/ as a middle-ground. It provides some fundamentals styles that aren't married to JavaScript, so there are never any conflicts with any SPA version. It's not widely used, but it worked well for us before going to Material UI as the team grew and the designers wanted something everyone is familiar with.

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

#389

Stop a second before you go into RSCs. Whatever you want to achieve ultimately is much easier/quicker/scalable done in real fullstack (or classic web-) frameworks! Rails/Django/Laravel/… + Turbolinks/Htmx/… or even sprinkle some light clientside JS for fancyness. Or go best-of-all-worlds if you happen to know Elixir/Phoenix. But don’t continue the descent into RSCs, now matter how many people tweet about it. These fo…

Indeed, RSC reminds me of CORBA [1]. CORBA is a way to mix local components with remote components. CORBA is very mature and works in many languages. So why doesn't everyone use it? I would guess that most developers today have never even heard of it. Why is that? I would suggest that anyone who wants to invent another distributed component architecture should study CORBA and its descendants and why they have never really caught on. (Hint: hidden component boundaries mean hidden complexity!)

Meanwhile, the "server-rendered HTML" and "client-rendered HTML" camps are both doing quite well. I consider myself quite lucky to have both options at my disposal for every web project. I hope the work on RSC doesn't muddy React's support for pure client-rendered apps.

1. https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...

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

#390
Wow... well, I'm not here to defend RSC or React as the best solution ever, but some of the objections here are half-baked. React/RSC is not technically equivalent in benefit to having a server return html/css with a smattering of javascript. It's still one app, with more intelligent handling of the client/server boundary (compared to SSR/hydration). I'm all for reading more informed objections about how React may have designed themselves into a corner and what the exit path is, but going back to php isn't it.
Post reply on HN