We are going back to the basics of composable architectures and highlighting some of the important jargon that is essential to understand when trying to build a modern web experience. In modern web development, there are always new trends when it comes to building digital experiences, whether they be fully embracing new technology or approach or swearing by a return to the basics and simplicity.
Here we will break down some of the differences between Single Page Applications, Static Site Generators, and Server-side Rendered Apps (SSR). These make up the backbone of modern web experiences. Each approach has use cases where they are ideal and where the type of content benefits from the frontend pattern. Dynamic content that requires a high level of personalization is likely better suited for an SSR approach, whereas static content that is SEO optimized may be better suited for an SSG site.
What is a Single Page Application (SPA)?Anchor
A Single Page Application (SPA) is a broad overarching term for applications that are 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 of the data relating to the application logic, UI, and communication with the server. Popular Javascript frameworks and libraries for building SPAs include all of the usual suspects of React, AngularJS, Vue.js, Ember.JS and Svelte, among others.
When users are navigating through the various parts of the SPA, there will not be any additional loading time between the different elements of the application. SSGs can also fall into this category once they have been loaded in the browser. Because everything is loaded on the client-side, teams must account for the wide range of clients, while still ensuring a quick, seamless user experience. With modern frameworks, code splitting enables the loading of some elements on demand which can help eliminate this problem.
The ProsAnchor
- While the initial load maybe longer, once the application has fully loaded, there will not be additional loading 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 ConsAnchor
- As the application grows in size and complexity, it can severely impact the initial load time which can lead to a deterioration of 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
What is a Static Site Generator (SSG)Anchor
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. 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.
The ProsAnchor
- 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 ConsAnchor
- 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
What is Server-Side Rendering (SSR)?Anchor
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. With SSR, 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.
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 e-commerce. 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.
The ProsAnchor
- 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 ConsAnchor
- SSRs typically require more API calls to the server
- SSRs by default are often slower than SPAs and SSGs
Which approach is better?Anchor
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. 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.
