3 ms·

It implements some patterns for rendering in both environments using the same code. The main problem with rendering in both the client and server environments

It implements some patterns for rendering in both environments using the same code. 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. On the server your code needs to fetch data during the render itself, whereas on the client you need to fetch data asynchronously then re-render with the data once it arrives (which in React means triggering the API call as a side effect, then setting the returned data as state, triggering a re-render). Unless you really need server side rendering and can't do it statically, Next.js is the wrong choice. IME like 98% of projects are just using it because the tech lead is resume padding or an idiot. The others are something similar to Reddit or Quora with a complex UI and dynamic data that needs to perform well on SEO. For those ones Next is probably a pretty good choice. Stuff like Next should be the 3rd tool in your arsenal after client and static rendering. It's a bunch of extra complexity for very little gain in most cases.

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.

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.