I Was Wrong About React Server Components... 

underrated comment

this comment looks AI generated.

@@Dev-Siri yes it's, I used ChatGPT to correct and improve the formulation of my sentences; however, this opinion is solely mine.

Without mentioning the goal of microservices which was INDEPENDENT DEPLOYABILITY first and foremost; something most indie projects obviously do not profit from

100%. Feels so much more like I'm "just writing javascript"

I'm a novice but I've watched a few of these videos about RSC and they seem really really cool. I'm yet to play around with them so will probably be a steep learning curve for me haha.

That's called sass.

Haha no

tailwind is server side

Because 99% of pages are misusing the SPA philosophy where they are even calling endpoints for static content. And if your whole website is 100% static then why outsource the rendering to the client when you can also do that. It’s all about user experience, which is dreadful in badly planned and coded SPAs. If this JS on service side push is the best thing to happen to web dev, is yet to be seen and to be discussed but I think we can agree that websites became a lot slower, riddled with thousands of spinners, freezes and other performance issues for absolutely no reason other than „it’s the coolest shit to do a client side rendered SPA“. Internet speeds evolved immensely, yet my page is full of loading…

@@boredbytrash No one is advocating a bad example. Instead of simplifying, things are constantly getting confused. Request an API populate data, request an API update data. Having everything on the user side simplifies things a lot. Take the api-level security measures and you're done. If SEO is important, fetch the first data on the server. Merge the client. (dehydrate). The React Server Component is overrated just so vercel can make more money.

Your problem is decades old code. Something like Laravel Turbo or Symfony Turbo along with Twig is really easy and nice to use from the limited experience I have with it. You basically have a hybrid between static and dynamic content and it all works through turbo-components in HTML. It's easier to work with than React in my opinion, despite having more experience with React. You have the same end result as well.

PHP/ASP never had these capabliliies. Doing some rendering on the server and some on the client is not something PHP/ASP could ever do.

@@maddogshwa Though technically correct, Turbo is something which creates the possibility of a similar effect, but it's really just PHP with some JS for the swapping, without needing to write JS. So I'd say everyone's moving toward the same goal overall. A hybrid.

We just need a full page refresh on every form submission or route transition, a more imperative way to change the UI, to give up this typescript thing and have DB calls inside the CSS, which is in a style tag inside the html file, which is a

How were you doing rendering in the browser in the 90's?

@@maddogshwa render html and send to browser, is that not react server components?

@@mjerez6029it's more like "pre-render html on the server specifically for the components I want, and only bundle the JavaScript for those components which need it for interactivity"

I'm a react/node web dev....how ever when I switch my job I was forced to learn php....before I just hated it blindly....but it's really amazing and simple how php handle things even without any framework... I'm in love with php now and no wonder why php is so popular

I find sending empty html and building it with clientside javascript is mentally the easiest to grasp and the easiest to develop with. But SEO people don't like that.

@@SandraWantsCoke It is simpler for simpler apps, if you try to make an ECommerce with hundreds of pages you simply cannot deliver a SPA, and in cases of complex apps using NextJS and Typescript will be easier, more complex yes, but easier at the same time since they come with advanced problem solution helpers

@@Ca-rp7bv youtube keeps deleting comments.... this site is so done. Seriously how many times I wrote a larger reply and it gets auto deleted (flagged by the A"I", intelligence in quotes).

​@@SandraWantsCoke There's also the option of "dynamic rendering" for SEO using something like "Prerender", if you want to just build a regular SPA, and only backend render for Googlebot etc. Much easier than dealing with all the quirks that come with SSR frameworks. But nobody seems to know about this option at all for some reason.

@@Ca-rp7bv I don't think you know what you are talking about but just repeating the points you have been told.

it's a pendulum moving within 3D space, where the additional axis is the quality of DX. We're not going back to RoR, because now the DX is way better than it is in RoR.

^ is right - "pendulum moving up". Heard the comparison of a spiral staircase once, dig that

Yeah i don't get it, why go back to the things we ditched (the monolith was too messy and unmaintainable) then we split responsibility, everything is better, then now back to the messy and very EXPERIMENTAL monolith? Just to please a few people doing TODO apps for a living

@@Davidlavieri I fundamentally reject that “everything is better” with the split. These tools don’t enforce monoliths. They’re new building blocks we can use to build better solutions for our users. Servers can now be built “backwards from the user” instead of building websites forwards from the API

​@@Davidlavieri How is it going back to the monolith? Now in your react code you just can query a database directly instead of querying an API. the huge advantage here is that now you don't need to write an API. so maybe a BIT more code in your app repo, but WAY less code if you include the API

So it not just me that going crazy. I feel like I'm taking crazeeee pills

More like a spiral than a circle.

PHP!

@@ricardomonge2769 Just wait 1 more year dude. These people will reinvent PHP and think they are the smartest people on earth. Hahaha. It's insane how all the points they said to bring php people into the js world, they are now forgetting and turning js into php.

Remember fb still uses PHP. Just sayin

It's the opposite. RSC is hard to grasp for experts, because they need to change their mental models. As a beginner, you don't have a mental model yet, so you are good building it from the concepts of RSC. An expert have to un-learn, then learn. A beginner just learns.

I agree with @Alber learning RSC hasn’t been that difficult for me so far, but it was probably difficult for Theo in the same way it’s “hard to teach an old dog new tricks”

To be honest I think it's a “forest for the trees” problem. People are so distracted by the implementation details of RSC that they don't appreciate the larger mechanism (don't get me wrong, details are important). After dissecting the 2020 December RSC demo my assessment was: “Largely a transport for server generated React Nodes to the client” much like one could splice HTML fragments sent from the server into the client's DOM. My understanding on the details has evolved since then but the bigger picture hasn't changed much. But I also noticed that for server-to-client component communication we have reverted back to the pre-context days where app communication passes through props. I still feel that a component tree, largely shaped by rendering needs, is a sub-optimal arrangement for the communication needs of an application's non-visual components.

I am afraid of accidentally leaking server stuff to the client when even the experts are confused at what runs on server and what on client. Also i feel like there are much better languages to build servers on then javascript. I am using it for the client just because choices are limited and WASM is still pritty new.

@@ParkourGrip Using JavaScript on the server is the easiest way to get around the “one app for the price of two” problem: Ryan Carniato «Exploring the App Directory in Next 13» 33m44s (2022-Dec-09) With other languages you tend to invite additional complexity. Some efforts with Rust are promising «Building Web UI's in Rust w/ Greg Johnston» (2022-Dec-09) but WebAssembly/WASI will continue to have its challenges.

Yes, client side interactivity, with server side rendering. I have similar feelings with respect to old ASPNET Web Forms, where you didn't even need to think about Javascript and AJAX - it would largely just handle it for you.

@@Leto2ndAtreides if the old lamp stack or whatever stack that can handle client component nicely without refreshing the entire page or losing lots of client states that is not need to be replaced, then React probably wouldn't exist at the first place. I'm surprised nobody invests on it after so many years from a MPA direction. It served well at its time when the web was still mostly static, but once I got used to the UX of SPA, every time I opened a MPA that requires some sort of interaction that causes page refresh (especially from those old enterprise products, interactive MPA), the UX always felt like an downgrade.

Another thing upsets me for a while is that a lot of devs wrote SPA in a MPA way, hence completely gave up the benefits of SPA, eventually produced a worse version of MPA. Then why border to migrate the application to SPA if it already ran well in MPA. Maybe it's due to market shift or how chaotic and fast-pace frontend tech evolves.

@@doc8527 I think I've heard of a simple client side JS router that will pre-fetch the HTML from all tags on the page, and just replace the when you click them. Honestly, I kinda wanna look into it, because it would give you that SPA feel of instant route changes while doing everything else in a classic MPA setup. SSR is already there by default since it would be server side rendered to begin with.

*Qwik

yeah, it feels like a major departure from the whole point of React-a highly _reactive_ frontend that's more of a client rather than a self-contained full-stack application. RSC/app dir are pushing a lot closer to PHP/rails development where you're just rendering templated code. great for full-stack apps, but doesn't work too well for scalable use-cases where the frontend is meant to be mostly separate from the backend

When you run out of ideas for your competing wars about being the top framework of the week

nah react is great mate don't worry about it

Honestly, that what makes him a MAKER. If you‘re never wrong that means that you are not evolving and doing something. The people on my team that did not introduce any bugs to PROD are the ones that just commit once a week. The overachievers on my team might produce a bug here and there, but they implement 10 new features a months.

@@boredbytrash 10 features a month doesnt sound like high quality to me, 4 a month maybe

​@@boredbytrash so faster but being less bug free. Sorry but it's just bad then.

@@boredbytrash No it's what makes him a RU-vidr with fantastic clickbait titles

Absolutely useful still. You can check auth on the server and redirect/throw/404 if the user isn't authed by returning different code. It's so clean.

What do you mean by making props an object first, like this? const customProps = { prop1: xxxx, prop2: yyyy } Where do the if statements fit in? Oo

why cheaper?

@@SandraWantsCoke yes that's basically it. I ended up needing some if statements for typeguards that I'd usually do as ternaries in JSX for example with a component where some props become required when using an icon

From a security standpoint, if you’re checking a user field for example for an existing user it makes it a lot easier to enumerate. You should still pass both user and pass at same time, and return only true false if it was successful. The whole “user doesn’t exist” and “password is incorrect for user” is exposing too much

If you have a sign up field you have to tell the user whether or not a user already exists anyway.

Personally I would use client side components for forms. But to comment on state quickly because this still blows my mind. An RSC can have client side state and when it re-renders it does that on the server while maintaining client side state.

Excalidraw

They're my friends and they definitely feel like it's a bit of a hack

"huge huge leap" sure... PHP has this model since it's inception and people only complain about how bad it is. Let's do the same in JS and people love it. Ridiculous.

Server Components/ Next13 effectively deprecated the T3 data fetching and any other react data fetching libraries when it was released - ive been saying this since it came out lol. Its funny how it took this long for Theo to realize what was going on lmao but then I have to remember hes not a staff architect

@@perc-ai Will react query still be good? I don't know much about the T3

@@upsxace its just additional boilerplate your adding to your code because NextJS will fetch at the server with its revolutionary app dir and use() hook

One obvious benefit I'm seeing is reduced bundle size. Let's say you have a large content site driven by a headless CMS site with hundreds of components. Most likely the vast majority of those components don't need client interaction so RSC makes a lot more sense than lazy loading those components for hydration. Less code in bundle means less parsing thus a faster TTI etc. This gives us more perf budget to spend on something more important like monitoring/telemetry etc.

@@vnrkk do you mean JS bundle size? Because unless there are metrics showing it's a noticeable improvement, I'm still skeptical that's more than a small advantage.

Excalidraw

shadowaccount Theo is that you?

Killer take.

I use nextJS and react, but they're right though. It's kind of hilarious

​@@ricardomonge2769 they're not right. PHP has never had client side AND server side rendering.

@@maddogshwa Laravel & InertiaJS

idk what you are on about KEKW