The growing divide among React developers…

Key Takeaways

Don't tell anyone, but while AI has been taking their jobs, react devs have been too busy fighting their own civil war to even notice. On one side of the battlefield, you have the rebels fighting for their women, children, and the simplicity of React tooling. On the other, you have Team Iceland from the Mighty Ducks trying to sell you cloud infrastructure and hosting services. In today's video, we'll break down both sides of the debate so you can be informed on all the latest React drama when you're standing in line at the soup kitchen. It is May 5th, 2025, and you're watching the Code Report. If you've been feeling happy or fulfilled over the last few years, you probably missed that React, everyone's favorite fun and flirty UI library, hit puberty, started rage listening to Limp Biscuit, and seemingly changed its whole identity. When React first launched, despite some early hate, it quickly grew in popularity because it made the view a function of your application state. And all you had to do was worry about how the state of your application changed, and React would handle the rest. React today follows the same ethos, but that's only half of the picture now. What used to be a client-only library has metastasized across the network to take over the server. Take this code for example. This is a perfectly valid React server component. It doesn't need to follow the traditional rules of React like not fetching data during render because it doesn't have the same constraints as a typical React component. In a way, you can think of server components as fancy serializable HTML template generators. Their entire job is to compute the UI and ship it to the client. Conceptually, this is pretty simple, but it enables some pretty cool stuff. And take this one for example. If this were a traditional React component, the entire pop-up library would be included in the JavaScript bundle that the user would need to download before sending anything on the screen. With server components, all that's shipped to the client is the end result of the computation. In this case, just the final table and some instructions for React to follow during hydration. And more important than the bundle may be the compositional benefits. Again, React pioneered the idea of bringing composition to the front end by allowing you to create a UI by composing different components together. all of which could be isolated from one another and each manage their own state. If done correctly, composition can lead to a more flexible, more maintainable, and more scalable codebase. It's what allows you to build complex UIs out of simple building blocks. And it's what allows you to then reuse those building blocks in a variety of different contexts. Combined with suspense, which is a React component that allows you to display a fallback UI while React works on rendering its children. The server components allow you to prioritize showing the user something immediately and then stream the rest of it as it becomes available. Composition across the network. This sounds awesome. So why is everyone so upset? Well, mostly because they contain more magic than that night in Las Vegas when David Blaine hypnotized me and told me to make JavaScript tutorials. What? Cheese it. Cheese it. Cheese. When a new React feature comes out, you can usually just npm install React at latest and you're good to go. With server components, though, that's not the case. In reality, you need three things to make them work. One, a bundler that can process and differentiate between server components and client components. A second, a server that can take the bundle that the bundler generates and stream it into the client. And third, a clientside router that can request and process the stream from the server. Since the average JavaScript developer doesn't understand what a bundler is without asking chat GPT, they usually can't get past number one. So, how did the React team solve this? By partnering with the Nex.js team and making a multi-yearlong bet that this new server components architecture would become the primary way to use React and therefore so would Nex.js. However, that bet according to many in the React ecosystem has failed. And there are really two separate problems here depending on which camp you fall into. If you're a developer, it's not so much that Nex.js JS is bad, it's that it's an implementation of the React team's full stack architecture vision. And unless you're building a web app that benefits from that architecture, it might not be worth the complexity. And if you're a framework author in the React ecosystem, the partnership between React and Next, it kind of feels like that winter your dad kept missing visitation days only to be seen with your stepbrother on Instagram skiing in Tahoe. But really, both problems stem from the same place. It's becoming increasingly difficult to separate React from Nex.js and even harder to separate Next from Verscell. If you don't like that Forcell's ultimate goal is to sell you Nex.js hosting services, you probably also don't like that React's new goal is to have you move as much of your app to the server as possible, regardless of how unrelated those two things may or may not be. So, if you're building a React app today and want to avoid the Verscell money machine, what are your options? Well, first you've got React Router version 7, formerly known as Remix. With a focus on web standards, React Router is the most popular routing library for React, and it can be paired with VIT to create a full stack React framework if that's your thing. Next, you've got Tanstack Start. Powered by Typescript and the man who single-handedly put the whole React ecosystem on his back for the last 5 years. Tanstack Start comes with full document SSR, streaming, server functions, bundling, and much, much more. It's still in beta, but that never stopped me from shipping to prod. And finally, if your app has constraints not well served by existing frameworks, at least according to the React team, you might just want to build your own. And the best way to learn how to do that is with the sponsor and provider of the visuals for today's video, React.gg. I've seen a lot of programming courses in my time and React GGG may be the best. It's so good because the entire thing has been developed to be as interactive as possible. For every topic, you get a video, some text, and visuals that represent core React topics in addition to a bunch of practical challenges that you can work through like le code for React. And just to make the course as real world as possible, the Sikos even built and published a hooks library called use hooks that now gets over 300,000 downloads per week. And you'll recreate it throughout the course. Whether you're new to React or just need to learn all the latest React 19 features like server components, actions, and transitions, I don't think there's a better way to do it than react.gg. And for the next week, you can get 25% off during their launch sale. This has been the Code Report. Thanks for watching, and I will see you in the next one.