3 ms·

> The main problem with rendering in both the client and server environments using the same code is that you need to fetch data in two different places. `getSt

by leerob 4y ago

> The main problem with rendering in both the client and server environments using the same code is that you need to fetch data in two different places. `getStaticProps` and `getServerSideProps` _only_ run on the server – it's possible we're conflating "rendering" with "data fetching" here. 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. > Stuff like Next should be the 3rd tool in your arsenal after client and static rendering. The philosophy of Next.js is that client, static rendering, _and_ server rendering have a place. For certain application holotypes, you might want all static. For others, all server-rendered. Next.js doesn't care - it allows you to choose which strategy you want on a per-page (e.g. route) basis. This allows you to not have to eject from the framework because your /contact pages wants to be static, while the /dashboard part of your site is server or client rendered. It also helps for incremental adoption.

BigJono 4y ago
> 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.

by leerob 4y ago

BigJono 4y ago

> 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.