Good write up, and the author certainly seems to really know their stuff.
I still like using Next, though. Some nitpicks:
> Elements that could change need to be inside a client component, but data fetching cannot happen on the client components, even during SSR on the backend. This results in awkwardly small server components that only do data fetching and then have a client component that contains a mostly-static version of the page
That's one way to do it.
I like flipping it, though - most of the page is a server component, with awkwardly small client components that sprinkle in just enough JS for things that need interactivity (such as optimistic updates from the above quote).
> Since the App Router starts every page as a server component, with (ideally) small areas of interactivity, a navigation to a new page has to fetch the Next.js server, regardless of what data the client already has available!
This is true, and something that Remix v1/v2 did a lot better than Next.
ahuth•3mo ago
I still like using Next, though. Some nitpicks:
> Elements that could change need to be inside a client component, but data fetching cannot happen on the client components, even during SSR on the backend. This results in awkwardly small server components that only do data fetching and then have a client component that contains a mostly-static version of the page
That's one way to do it.
I like flipping it, though - most of the page is a server component, with awkwardly small client components that sprinkle in just enough JS for things that need interactivity (such as optimistic updates from the above quote).
> Since the App Router starts every page as a server component, with (ideally) small areas of interactivity, a navigation to a new page has to fetch the Next.js server, regardless of what data the client already has available!
This is true, and something that Remix v1/v2 did a lot better than Next.