> You fetch the data on the server, and send pre-rendered HTML to the browser. You can, of course, also do client-side data fetching (e.g. `useEffect`) as you m

> You fetch the data on the server, and send pre-rendered HTML to the browser. You can, of course, also do client-side data fetching (e.g. `useEffect`) as you mentioned. That's only if you're loading the app from the server on every page transition, in which case you may as well use PHP or something to do old school server rendering. The whole point of hybrid SSR is to get a fast first paint but still have the snappiness of client side navigation. The first page loads data from the server but subsequent pages need to fetch it, including returning to the original page. Meaning every page that's both tied to a URL and navigable through the UI needs to support both paradigms. > The philosophy of Next.js is that client, static rendering, _and_ server rendering have a place. Their philosophy is whatever will get the most people to use their tool, whether they need it or not. My philosophy is that 5% of apps need hybrid SSR at best and the rest should use something else. All 3 paradigms have their place, but not all in every codebase. The majority of apps don't need static rendering either. And static sites don't need client rendering.