Server side rendering is about having the content generated at server than at browser. Traditionally all web content were rendered at server as response to HTTP requests. With advancements in java script engine and browser capabilities, it is now possible to have seamless experience generating and manipulating the DOM within browser itself. It helps with lesser load on server and minimized network traffic. Since DOM manipulations are done by JS, the scripts for the same could be bundled and cached on browsers or CDN, there by improving the latency issues. This led to evolution of single page applications, where there is only one HTML page with supporting JS code, listening to browser history for route changes, and manage the DOM interactivity; giving users the perception of page transitions on routes. However, SPA comes with overheads of high initial js bundle size and problems with SEO. SPA libraries have evolved to cater to these limitations by means of lazy module downloads on route changes, server side rendering methods, hydration of state etc. As rightly mentioned by Jos, you would have to take a choice depending on what you want to build, whether the content is static / dynamic, potential user base, access channels (mobile / legacy browsers etc.), hosting environment needs(CMS / Static servers, portal containers etc), potential need of forwards / redirects at server, contextual HTTP headers etc.