Server-side rendering is the most common approach for delivering the data and HTML to the client side on the browser on your screen. It was the only way to do things when the web industry just started. In traditional server-rendered apps or dynamic websites, every request requires a new page re-rendered from the server to the browser. This means you will reload all the scripts, styles, and template(s) once more with every request you send to the server. The idea of reloading and re-rendering does not sound compelling and elegant at all. Even though some of the reloading and re-rendering burdens can be lifted by using AJAX these days, this adds more complexity to the app.
Let's go through the advantages and disadvantages of these types of apps.
Advantages:
- Better SEO performance: Because the client (browser) gets the finished page with all the data and HTML tags, especially the meta tags that belong to the page, search engines can crawl the page and index it.
- Faster initial load time: Because the pages and content are rendered on the server side by a server-side scripting language such as PHP before sending it to the client browser, we get the rendered page fast on the client side. Also, there is no need to compile the web pages and content in JavaScript files like we do in traditional SPAs, so the app is loaded quicker on the browser.
Disadvantages:
- Poorer user experience: Because every page has to be re-rendered and this process takes time on the server, the user has to wait until everything is reloaded on the browser and that may affect the user experience. Most of the time, we want the new data only when provided with the new request; we don't need the HTML base to be regenerated, for example, the navigation bar and the footer, but still, we get these base elements re-rendered, regardless. We can make use of AJAX to render just a particular component, but this makes development more difficult and complex.
- Tight coupling of the backend and frontend logic: The view and data are usually handled together within the same app. For example, in a typical PHP framework app such as Laravel, you may render the view (https://laravel.com/docs/7.x/views) with a template engine such as Laravel Pug (https://github.com/BKWLD/laravel-pug) in a route. Or, if you are using Express for a traditional server-side rendered app, you may use a template engine such as Pug (https://pugjs.org/api/getting-started.html) or vuexpress (https://github.com/vuexpress/vuexpress) for rending the view (https://expressjs.com/en/guide/using-template-engines.html). In these two frameworks for a typical, traditional server-side rendered app, the view is coupled with the backend logic, even though we can extract the view layer with a template engine. The backend developer has to know what view (for example, home.pug) to use for each specific route or controller. On the other hand, the frontend developer has to work on the view within the same framework as the backend developer. This adds more complexity to the project.
