The more features React adds the less I end up using React. The new additions are just so inelegant, and don't fit my brain. The function useEffect has so many caveats and such a terrible API. A magic "use client" string at the top of a file is just ridiculous. React code is nearly impossible to understand and write without extensive external documentation now. I feel sad for the future developer that has to modify this type of code ten years from now; I hope Google is good at searching decade old documentation to figure out what the hell is going on in old React code.
It's annoying that the React team announced Server Components without a well defined spec, the wire protocol most significantly. Instead, it's a cabal between the React team and Vercel which obviously is going to give them an inherent advantage and probably steer things in their favor, rather than the broader React ecosystem as a whole.
I will have to give this article a more full read rather than just a skim, but...
I am left with such confusion as to how React/Next arrived at this solution. `useEffect` didn't run on the server when doing SSR, great, easy enough to understand. Now several common hooks don't run on the server because they are considered interactive? And it isn't that they won't run, their initial pass in most cases doesn't do anything, it is that Next now yells at you for having a `useState` hook in a "Server Component".
I would like to write a component, not have to think about where it is running in most cases, and go on with my day. I mostly use React for large SPAs and have adopted Next for doing SSR on the few pages that I needed it for (SEO, etc).
> In order for this to work, we'd need to be able to give React a chunk of code that it runs exclusively on the server, to do the database query
This is not true/it’s misleading. What you need is to be able to fetch on the server, and hydrate on the client using data from the server. This is possible with SSR and injecting into the React stream, using isomorphic (client) components.
The article is great, but the reasons for RSC are more subtle/complicated than the flow of the article would imply.
> This tutorial is written primarily for developers who are already using React
Also good for those moving away from React, since we understand React too. Probably won't change it, but may give us things to look for in our new frameworks. A former coworker who was really into React just switched to Flutter.
Hilarious that the industry is going full-circle back to server rendered pages.
A lot of people are complaining about NextJS + Vercel lock-in
RSC locks you into their hosting solution and the way they suggest you to use it also locks you into NextJS way of building your backend data layer (ie PHP/JSP/ASP-like with our without MVC)
But their routing things locks you into NextJS as a framework. Just remember how much people complained about migrating from react-router v4 to v5 (or was it v5 to v6?). Migrating from a routing solution is a huge pain in the ass. I am still unconvinced that file-system based routing is better. It is at best a replacement for lack of guidelines in most routing libs on how to organise your components for routing.
I am also very weary of anything that takes over the bundler, bundling is a hard problem and just outsourcing it is asking for trouble. But I understand why a lot of people don't want to deal with it, it takes a huge codebase for bundling to become a big issue.
I am looking forward to Bun: https://bun.sh/
Which promises to reduce the tooling headaches to get a project going without using a bunch of frameworks. Their bundler though is still nowhere near ready so I wouldn't recommend it for frontend projects yet. Using Bun just to run nextjs/webpack/whatever on top of it also doesn't seem like a good solution to me.
Bun might support RSC in the future, but in my opinion RSC is a very specialised tool to be used only in a few critical places in your code and it is scary how Vercel is pushing for it so hard in their docs. You have to remember that the average new frontend developer now uses "create-next-app" not "create-react-app" and is introduced to RSC right away
Server side rendering isnt special any more:
https://joshcollinsworth.com/blog/antiquated-react#server-si...
This blog was posted to HN a few weeks ago. The author does a really good job of summarizing React's relationship with the rest of the SPA ecosystem.
so ... ColdFusion custom tags?
This is my first time really reading about them, I'd assumed they'd do some ASPX style interactivity where server components updates on the server and send back html, it's interesting that they haven't tried to go for something like that, meaning this is a lot more limited in scope in some ways than I'd thought.
How does it handle flaky connection or even offline scenario? How does it work with service worker?
> As I write this, there's only one way to start using React Server Components, and that's with Next.js 13.4+
I don't understand how this is acceptable to the React user community, that only Vercel gets to be in this privileged position. Why did they not include other companies, or the users themselves, in the discussion and development of this feature.
> Since Server Components are a new React feature, third-party packages and providers in the ecosystem are just beginning to add the "use client" directive to components that use client-only features like useState, useEffect, and createContext.
> Today, many components from npm packages that use client-only features do not yet have the directive. These third-party components will work as expected within Client Components since they have the "use client" directive, but they won't work within Server Components.
The arrogance of expecting all third-party packages, React-related or not, to buy into the "use client" directive. A humbler approach would have been a "use server" directive to opt-in to this behavior, instead of expecting the entire rest of the ecosystem to adapt to it.
> Instead of bouncing back and forth between the client and server, we do our database query as part of the initial request, sending the fully-populated UI straight to the user.
> But hm, how exactly would we do this?
Couldn't help but chuckle. What mysterious technology could allow us to send an entire fully-populated UI over the web?
[flagged]
I'll do what I did the last time one of these articles popped up. Word counts:
complex: 2
confusing: 3
[flagged]
The last decade of web dev can be summed up as:
– A bunch of smart Facebook engineers with unlimited funding decided to mess around and see just how much they could upend all the existing web paradigms, before finally concluding that conventional wisdom and the traditional server-side rendering model exist for a reason and make sense.
– The entire software industry decided that every new experiment by this above group was worth ripping out and rewriting their entire codebase over, whether it made sense for their needs or not and whether it actually made their product better or not.
I have not been too deep into the weeds of it myself but have been interacting with FE teams at my company enough to see what a charade it all is.
"This React thing is cool, and everyone is talking about it. Let's move some of our existing JS components over to it and see how things turns out."
"We need to do a top-down rewrite of the entire app in React."
"We're going to need the infra team to set up a GraphQL API layer for us. It can't be that hard, right?"
"Hmm, initial page loads are too slow. Hey infra team, can you set up a render farm of Node.js servers so we can do SSR?"
"Whoa, functional components are cool! We need to do another top-down rewrite and get rid of all the silly classes."
"We have a small team dedicated to investigating server components, and if the prototype looks good then we'll switch over to Next.js and rewrite our FE + API stack."
I'm sure my company wasn't the only one that caught this virus. I shudder to think just how much money and productivity has been wasted industry-wide over the obsession with this framework.