Server-side rendering versus single-page apps
In Chapter 4, Serving and Embedding HTML Content, we created our app as a server-side rendered app. What this means is that all of the content and assets, including the HTML, are generated on the backend and sent on each page request. There’s nothing wrong with this; our publisher, Packt, uses server-side rendering (SSR) for its own site at https://www.packtpub.com/. SSR as a technique is used by technologies such as WordPress and many other sites that host content that changes less frequently and may have less interactivity.
The alternative to SSR we’re going to use for our app is client-side rendering (CSR). CSR works by having the client fetch the app as a bundle of JavaScript and other assets, executing the JavaScript and the app dynamically, and binding to an element that takes over the page rendering. The app creates and renders each route dynamically in the browser. This is all done without requiring any reloading of the bundle or content.
By moving to client-side rendering, it improves the app's interactivity and responsiveness by allowing it to manipulate the document model, fetch additional content and data via the API, and generally perform closer to what a user might expect from a desktop app without constant page reloads.
When we talk about reactivity, we’re describing the situation in which changes in the application state are automatically reflected in the document object model (DOM). This is a key attribute of all of the frameworks we’ll be exploring in this chapter, including React, Vue, and Svelte.
