We are going back to the basics of composable architectures and highlighting some of the essential jargon to understand when building a modern web experience.

Building digital experiences in modern web development brings new trends every day, whether it's fully embracing new technology or approaches or going back to basics.

Here, we will break down the differences between Single Page Application (SPA), Server-Side Rendering (SSR), and Static Site Generator (SSG). These make up the backbone of modern web experiences. Each approach has ideal use cases where the type of content benefits from the frontend pattern.

#What is a Single Page Application (SPA)?

A Single Page Application is a broad overarching term for applications rendered when the client requests them. SPAs are structured as a single HTML page that has no preloaded content. Content is loaded via Javascript files for the entire application and housed within a single HTML page. The Javascript files house all the data relating to the application logic, UI, and communication with the server.

Popular Javascript frameworks and libraries for building SPAs include all the usual suspects of React, AngularJS, Vue.js, Ember.JS, and Svelte, among others.

When users navigate the various parts of the SPA, there will not be any additional loading time between the different elements of the application.

The Pros

• While the initial load may be longer, once the application has fully loaded, no additional loading is required.
• Good choice for dynamic experiences where teams need a customized feeling to their user experience
• Teams have a lot of control over their architectures and can make use of modern web frameworks
• Can be used in tandem with other technologies

The Cons

• As the application grows in size and complexity, it can severely impact the initial load time, which can lead to a deterioration of the user experience
• Maintaining good SEO is nearly impossible because of load times and lack of initial content on the HTML
• Large files for complex web applications can become difficult to maintain and organize
• Challenges with the SPA approach require workarounds that can be costly and time-consuming

When to use Single Page Application

While SPAs are excellent at delivering interactive, personalized experiences, it is not recommended to work with content-heavy ideas due to their long loading times.

#What is Server-Side Rendering (SSR)?

With Server-side rendering, clients receive a fully rendered page on demand rather than having to wait several seconds for specific elements to load. The rendering occurs on the server before passing them on to the browser. When content is requested on the client, data is fetched from a database or CMS as the user navigates the page.

Loading everything on demand makes it slower but ensures that content is up to date and that any changes are available live. Some elements can be cached, such as assets and CSS files, and even some server-rendered pages, but typically data is pulled directly from the database upon request.

The Pros

• SSR enables teams to create dynamic, personalized content experiences without labor-intensive workarounds
• Changes to content are displayed instantaneously unlike SSGs where teams must rebuild the site to see the changes to the content
• SSR sites are client agnostic, different from SPAs where clients can determine page loading time or quality
• It is easier to rank well for SEO with SSRs than SPAs, while still providing personalized experiences

The Cons

• SSRs typically require more API calls to the server
• SSRs by default are often slower than SPAs and SSGs

When to use Server-Side Rendering

Server-side rendering enables teams to provide dynamic content experiences that can be personalized. They are ideal for personalized experiences where live changes to the data can be viewed.

Server-side rendered sites (or server-side rendered applications (SRAs)) are excellent choices for content that is time-sensitive and applications that rely on large amounts of user interaction. With SSRs personalization is much easier and can be a good option for eCommerce. With SSRs, it is important to make sure your infrastructure can handle the requests to the servers and that the servers are able to easily scale as traffic continues to rise.

#What is a Static Site Generator (SSG)

While SPAs load all of their data on a single HTML site that is rendered only after a client request, static site generators take a very different approach to content and to building pages in general.

Static Site Generators generate content at the build time of new pages or when changes are made to the content. Because the SSGs are creating static sites, there is no need to load pages based on user requests. The content will remain consistent regardless of users.

The Pros

• Easy to create decoupled architecture with multiple content sources
• Fast page load times due to much of the content being pre-rendered and the static nature of the content
• Better for SEO
• Easily scalable infrastructure that allows the project to grow organically

The Cons

• Personalization and dynamic content require workarounds or additional services
• When content does change, you must rebuild the site in order to have these changes reflected on the site

When to use Static Site Generator

Employing SSGs as part of the tech stack enables teams to pull data from multiple data sources and lets teams take advantage of modern approaches to web development. Use cases that are ideal for the SSG approach are those where content does not need to be highly personalized.

Static site generators are typically used in concert with a headless CMS, a static hosting site, and a CDN to cache all of the data. Webhooks trigger to the SSG that there have been changes in the content and the changes are deployed to the site which is stored in a cache. CDNs enable teams to store pre-rendered HTML files in places that are geographically closer to the request, further reducing page load times. We’ve gone into depth on SSGs and their benefits in other posts but here are some highlights on the pros and cons of SSGs.

#Which approach is better?

Like many things in web development, there is no definitive answer on which is better, but rather, it depends.

It depends on the use case and content in addition to the audience, the development team, budget, etc. SPAs with client-side rendering can be more effective for creating dynamic web experiences; however, teams will face the challenges of page load times and may struggle with SEO. Dynamic content that requires a high level of personalization is likely better suited for an SSR approach. SSGs enable teams to build static sites that load quickly and perform well with SEO but may limit the amount of personalization and dynamic content available without labor-intensive workarounds.

There are some tools that can help bring together modern frameworks with greater flexibility. Next.js enables you to create static sites and use server-side rendering using their hybrid approach. Meaning that teams can reap the benefits of SSR or SSG depending on the ideal use case for the elements of their project. Working with Next.js can be helpful to ensure that projects maintain good SEO.