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
To understand why React is moving in this direction of recommending frameworks, it's worth noting what they said at Next.js Conf 2022.
Or to solidify this further, it's worth reading Dan Abramov's thoughts on Next 13.
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.
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 React Beta 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.