React Development is About to Change
Next 12 introduced an alpha version of server components but it seems not a lot of people bothered to try them out. But with the introduction of nested layouts and server components as a default in beta with Next 13, it seems everyone is jumping to try to get it all implemented and working as soon as possible.
I will say that layouts are rough. Unless you're doing everything static, there are a lot of issues. A lot of components that use React hooks just don't work with “client components”. Third party libraries aren't likely to work with Next 13 layouts just yet.
That being said, this is all bringing huge changes to the way we build React apps. Whether you use NextJS or not.
React is Officially Recommending NextJS
If you're learning React, we recommend Create React App. ... If you're looking to start a production-ready project, Next.js is a great place to start.
- Start a New React Project
To understand why React is moving in this direction of recommending frameworks, it's worth noting what they said at Next.js Conf 2022.
I've been thinking of NextJS 13 as really like, this is the real React 18 release. Because even though we have a lot of primitives in React 18, you can't really take advantage of them unless you have a framework that takes... that is built on top of those architectural primitives. So on Facebook.com, Facebook has an infrastructure that's based on Relay and some other routing concepts that... I mean one way to think of it is that NextJS is an open source implementation of that. In some ways it even goes a step further now with server components. I'm really excited for the rest of the React community to now be able to take advantage of all of these improvements that we spent so many years researching and building.
- Next.js Conf 2022
Or to solidify this further, it's worth reading Dan Abramov's thoughts on Next 13.
on the other hand, for the past five years, much of our work has been directed towards features that can only truly shine within a deeper stack integration. the most basic one is server rendering; it makes sense to render React to HTML, but this requires a bit of manual wiring!
- Dan Abramov
this is why I like to think of React as two things. React is a library. it is *also* an architecture (which frameworks may implement). this architecture doesn't specify things like filename conventions, but it's focused on pieces where deep integration with React has most value.
- Dan Abramov
Caching = Global State
You may have already ditched global state providers like Redux for client-side cache invalidation via React Query or SWR, and switched to Reacts recommended way of handling state management. (Harry Wolff recommended this pattern 2 years before it became a part of official docs.) If you have, you're already familiar with this concept, if you haven't, it's coming.
Not only does the new router in Next 13 introduce global caching and deduplication, but React is now overriding the global fetch method to add caching. Of course this is a very controversial decision as overriding native methods isn't exactly in good taste.
But overall the point is, with data fetching handled by built in caching in both React and NextJS, the need for state management decreases significantly. Suddenly the idea of only creating small, scoped contexts, makes a lot more sense than a global provider.
It's important to remember that NextJS components in the beta app/ directory are server side by default. And on the server, context doesn't exist. I would of course say to avoid the temptation to just make everything client side just to force old mental models.
I have enough experience building highly dynamic complex apps without global providers to give the “but my app is bigger than your app, you just don't understand” much attention.
Edge Deployments
Serverless deployments are coming in hot whether we want to embrace it or not. There is still a minority of projects out there trying to deliver React apps as a single bundle on S3 buckets or CDN.
This is not realistic for the modern dynamic app. As apps have grown, we know the performance hit they take on hydration. Trying to load all JS at once just doesn't make sense. Nor does it make sense to make everything static again.
By delivering frontend servers to the edge that can build, render, and create a client side cache for each user, we can have customizable, dynamic experiences without the sacrifice to performance.
It's Not Just NextJS
It's not just that React has cozied up close with Vercel. Or it's not that Vercel has just influenced React. Shopify Hydrogen and Gatsby have been very influential in making these changes too. Because they're all trying to solve the same problems.
This has been a collaborative effort and many years of work to make happen. If you haven't already, it's worth going in to the new React documentation and NextJS Beta documentation with a clear mind and intention to relearn everything you know about working with React. Because I believe this is the direction the rest of the world is going to go in with or without us.