| I was confused with this initially as well. What I came to understand, was that "server-side rendering" refers to whole application lifecycle steps:
- The server generates initial HTML markup, based on the request.
- The browser can parse & render the already generated HTML (instead of waiting for the client-side JS to load first, then have it create / modify the DOM).
- From that point onward, all changes in UI happen through client-side rendering. You could do this with Django template / JSP pages / Jade templates as well. Just write your templates, and some jQuery sprinkled here and there, to dictate how user interaction should change the page. But that's not all there is to it. We slowly took away SSR, with client side JS frameworks, like Backbone, Angular 1, Ember etc. Applications started to have client side routes, even with ugly hashbangs in the URLs. It was easier to write entire application logic of your UI in a client-side framework with two-way data bindings; than writing the server side in a template language, and put in some JS here & there to handle interactions. Especially, if your application was big enough. But this started having problems with SEO, and initial load times. Say, your app has a homepage URL, of the form https://company.tld/, and a products URL, of the form https://company.tld/products. If a user goes to homepage, and clicks on the "products" link in the navbar, the page content of /products route would load in the client side, via the framework. But, if a user directly hits the /products URL from their browser (can be from history and omnibox prompt), the browser would first load the home page with assets, then the client side JS would take over, and route the user to the /products URI endpoint. New server-side rendering paradigm gives you best of both worlds - get to maintain a single codebase to render your page (be it server or client), while give the initial fast loading, so that your page is interactive quite fast. This is not easy to do. One big challenge for most server side rendering solution is that, after initial render, the JS in the page would try to re-render the page; thereby creating an impression of a "flash". Yes, if you're using a framework like React or Vue, which uses VDOM, this won't happen in most cases, because of how a virtual DOM based renderer works. But there are still cases, where you might need to explicitly do something to prevent the re-render. There are other challenges too. For instance, having the page server-rendered, and hydrating the state. In the search of maintaining a single unifying codebase for both server and client (isomorphic rendering), we often do things that cannot work on server. For instance, chunk splitting your front-end bundle based on routes. Or CSS media queries. To sum it all up, "server-side rendering" isn't just about initially rendering the page on server. It's so much more than that. It's mostly about how we can maintain a single codebase (now that we have JS on server too), and run on two different platforms. |