4 ms·

In some ways, React on the server is worse than PHP. Server-side rendering of client-side code adds a ton of complexity, and can even introduce performance issu

In some ways, React on the server is worse than PHP. Server-side rendering of client-side code adds a ton of complexity, and can even introduce performance issues that must be worked around before the app can be launched (e.g. needing to pre-warm caches). I'm sure there are valid uses for server-side React, but at the end of the day, using server-side languages such as PHP or Rails (or even rendering pages in Node.JS if you like JavaScript) can be much faster and simpler. I say this having been involved in an app rewrite that used Remix. The project has taken 2 years (and still isn't quite out), and the engineering leaders who made the decision have agreed that we probably could have rendered most of the pages in Rails and used JavaScript for a limited number of things. With that said. I am hopeful that the project will work well when all is said and done, but there were a lot of tradeoffs associated with going to a server-side rendering framework.

willsmith72 2y ago
what do you mean by performance issues like pre-warming caches? you mean with other backend frameworks you wouldn't have the same issues? or with clientside-only rendering?
- dlevine 2y ago
  The first time you server a page with a SSR-framework, it will be slow, and subsequently it will be fast when it is served from cache. What I have seen is that, depending on the number of pages and frequency that each page is accessed, it may be necessary to pre-cache some or all of the server-side rendered pages to get good performance.
  - willsmith72 2y ago
    Define "slow". You shouldn't have to cache every page on your website just to get decent performance. Sounds like something else is wrong. If your site is in any way dynamic, you won't be able to cache much anyway
    - dlevine 2y ago
      The use case I'm working with right now is eCommerce. Landing pages need to be served as quickly as possible to score highly on various page speed SEO metrics. I have seen a number of server-side implementations that need to have most of the common landing pages cached to score better than client-side rendered pages. Many of these page renders require calls out to third-party APIs, which is responsible for some of the slowness. There are definitely optimizations that can be performed (e.g. caching the results of the backend APIs). But it's easier for less experienced developers to just cache the whole page with a reasonable TTL. Also agreed that you won't be able to cache much (or as much) if the user is logged in. Logged in pages matter less for SEO, so we haven't focused too much on it.

willsmith72 2y ago

what do you mean by performance issues like pre-warming caches? you mean with other backend frameworks you wouldn't have the same issues? or with clientside-only rendering?

dlevine 2y ago
The first time you server a page with a SSR-framework, it will be slow, and subsequently it will be fast when it is served from cache. What I have seen is that, depending on the number of pages and frequency that each page is accessed, it may be necessary to pre-cache some or all of the server-side rendered pages to get good performance.
- willsmith72 2y ago
  Define "slow". You shouldn't have to cache every page on your website just to get decent performance. Sounds like something else is wrong. If your site is in any way dynamic, you won't be able to cache much anyway
  - dlevine 2y ago
    The use case I'm working with right now is eCommerce. Landing pages need to be served as quickly as possible to score highly on various page speed SEO metrics. I have seen a number of server-side implementations that need to have most of the common landing pages cached to score better than client-side rendered pages. Many of these page renders require calls out to third-party APIs, which is responsible for some of the slowness. There are definitely optimizations that can be performed (e.g. caching the results of the backend APIs). But it's easier for less experienced developers to just cache the whole page with a reasonable TTL. Also agreed that you won't be able to cache much (or as much) if the user is logged in. Logged in pages matter less for SEO, so we haven't focused too much on it.