You Might Need Server-Side Rendering
There’s a popular idea within the React community that SSR (server-side rendering) isn’t necessary, and it’s a popular idea for some very attractive reasons.
Firstly, it’s not trivial to get SSR working well. It involves a lot of bootstrap code on both client and server, and it often needs to be highly bespoke to your particular project. Additionally, React is very slow at rendering a component tree to a string on the server (there are tricks to speeding this up, but the most effective ones are a little… dirty). There are also tricks you need to do on the client to deal with interactivity issues related to pre-rendered content.
Even if you don’t care about the SEO of your particular project, usually because it’s an app and content doesn’t need to be indexed, you may still need SSR.
At my day job, we went down the route of implementing SSR, and as expected we found it to be an error-prone and complicated process. Then we fell into the trap of thinking we didn’t actually need it for SEO (due to all the popular reasoning), so we stripped it all out — ending up with a much cleaner codebase. It was only when we came to implement Twitter Cards and Open Graph that we realised that we really did need SSR. Thankfully this all happened in the early stages of the project architecture, so the costs of change were low, if it had happened later it could have caused some major delays.
The lesson here isn’t you should always implement SSR, just that there are good reasons for doing so that you may have overlooked.
Aside: I love the mild irony that Facebook hasn’t put a lot of effort into supporting SSR in React and Relay, mainly because they don’t need or use it — but Facebook itself is one of the reasons that other people do need it. ;)