Introduction
Server-Side Rendering
When we talk about the server-side rendering of websites, we generally refer to an application or website that uses a programming language that runs on a server. On this server, web pages are created (rendered) and the output of that rendering (the HTML) is sent to the browser, where it can be displayed directly. Examples of this include PHP, Java, Python, .NET, and Ruby.
Strengths
The benefits of server-side rendering is that the generation happens on a server, making it ready to consume in the browser once it's downloaded. It works great with indexing by search engines and with sharing on social media. The content is ready to be consumed, and the client (in this case, the search engine) does not need to run any code to analyze the page.
Weaknesses
The downside of server-side rendering is that the pages often have only basic possibilities of interaction with the user, and when the content changes, or the user navigates to another page, they have to re-download the whole page. This results in more bandwidth and gives the user the feeling that the page is loading slower than it actually is.
Client-Side Rendering
When we talk about client-side rendering, we generally refer to an application or website that uses JavaScript running in the browser to display (render) the pages. There is often a single page that is downloaded, with a JavaScript file that builds up the actual page (hence the term single-page application).
Strengths
The benefit of client-side rendering is that the pages are highly interactive. Parts of the page can be reloaded or updated without having to refresh the whole browser. This uses less bandwidth and it generally gives the user the feeling that the website or application is very fast. The server can be mostly stateless as the page is not rendered there; it just serves the HTML, JavaScript, and stylesheets one time and is done. This takes load off the server, and this results in better scalability.
Weaknesses
Client-side rendered websites are difficult for a search engine to index, as they need to execute the JavaScript to display how the page looks. This is also the case when sharing links to the sites on social media, since these are generally static instead of dynamic.
Another weakness is that the initial download is bigger, and this can be an issue on, for instance, mobile devices with slow connections. Users will see a blank page until the whole application is downloaded, and maybe they will just use a small part of it.
In this chapter, we will create an Angular application that is used throughout this book.
The Angular application we will build is going to be a list of posts that you regularly see on a social networking site such as Twitter. From the list of posts, we can click a link that brings us to the post detail page. We will intentionally keep the application simple as this book is meant to focus on the technology rather than the functionality of the app. Although the app is simple, we will develop it using best practices for Angular development. It should be easy for any Angular developer to extend on the logic and structure that is shown in this application.