28 Jun · 6 min read
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.
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.
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.
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.
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.
Author: Emily Nielsen
Leave a comment