SPA, SSG, SSR and JAMStack: a front-end acronyms guide

In the last decade, front-end development went through multiple paradigm changes that make it hard to follow.

Moving from jQuery / Mootools to Angularjs and then React/Vue/Angular was exciting but hard enough. Now comes Gatsby, Nuxt, Gridsome, and their friends that take pleasure in rocking our developer’s world once again.

In this article, we will tackle the new patterns for front-end web development, to see what they bring to the table and how you can implement them today with the proper tools.

Single Page Applications

Single Page Applications really took off in the early 2010s, when AngularJS popularity made front-end developers want to code their entire app content and flow in JavaScript instead of having the traditional HTML/CSS/JS files for each page.

The idea behind Single Page Applications (SPA) is to develop websites the same way you develop mobile or desktop client apps:
Your app source code (mostly JavaScript) is responsible for filling, interacting and navigating between your application contents inside the available renderer (your user’s web browser).

So instead of having multiple HTML pages that load different CSS and JavaScript resources, and your browser navigating between those pages using links, with SPA you have a single HTML page (index.html) with no content, loading one or many JavaScript files that will render your content, navigate between sections of your app and handle any interactions between your DOM components.

They make use of the following pieces of technology:

• HTML5 history API (or location hash #): this API enables perception of navigability between your website page, making navigation compatible with native browser behaviors (previous / next buttons and URL changes)
• JavaScript Web Framework: React, Angular, Vue all handles decoupling content representation from the data, and the rendering and updating of such data to the DOM. This model simplifies the making of data intensive application, and are inspired by the MVVM architecture of client side app.
• Ajax and HTTP APIs: Since the app’s initial page is empty, the JavaScript code will often call an API to get user contents. These API usually use REST protocol with JSON as their data format, but lately GraphQL has provided a flexible alternative for content querying.

Because you probably don’t want to write your app in a single JavaScript ES5 file, modern tooling provides a build tool chain (webpack being the most prominent bundler at the moment) that enables you to code your app in a structured and dev friendly environment (ES2020 standards, components tree), and compile it to minimize, concatenate and chunk your JS & CSS files into a build folder.

Plus, modern framework usually comes with their own HTML like syntax (JSX, vue HTML-based templates) to enhance the HTML language with dynamic features such as data interpolation and event binding.

So, to sum up, here is what SPA bring to the front-end development world:

• The ability to use new frameworks that ease up development of highly data-bound and interactive applications.
• The ability to architect your code the way you like it and have it built on a single deployable package (HTML, JS, CSS)
• Since your application is loaded all at once, the later navigation and interactions will generate no asset requests, such making it faster than traditional full-reload navigation
• SPA makes use of APIs to query your application’s content, such encouraging decoupling between data and its representation

But those advantages also come with trade offs, such as:

• The overall size of your app bundle can get quite big, thus slowing down the first loading of your application
• State management can get complicated, because with JavaScript navigation your application state do not get reset on page navigation (you do not get the clean slate of a full reload). Redux/Vuex or React reducer hooks make it easier though.
• SEO can be tricky: even though ajax crawling of indexing robot exists, it is commonly accepted to say that server rendered HTML pages will be easier to optimize as SPAs.
• Performance can be impacted: as your app grows, more and more JS code will be run to render your app, which can make your visitors CPU run wild. Fortunately, most frameworks recommend best practice such as using memoization to prevent too many re-rendering of the DOM.

Overall, Single Page Applications enables you to embrace the spirit of modern JavaScript frameworks (ES2020, component architecture, bundling and optimization, HTML5 history API), but comes with some challenges if you want the best SEO and UX experience.

Static Site Generators

https://www.netlify.com/blog/2020/04/14/what-is-a-static-site-generator-and-3-ways-to-find-the-best-one/

Early Static Site Generators have been around since 2008 (Jekyll), and I think they wanted to provide an alternative to CMS based web applications.

Indeed, a lot of website display content to all their users that is edited by a CMS (like Wordpress). That allows changes made in the CMS to be deployed directly to user, because the content is generated at run time (event request time for PHP based CMS).

What SSG challenge is the hypothesis that content should be request from the database for each request from a user. Indeed, what they suggest is to generate content at build time instead. Because once your pages have been generated from the CMS, that’s it, it won’t need to be changed until the next content change in your CMS.

So why not generate all your website pages as static pages each time your content changes ?

The way it usually work is you’ll connect your content (CMS, headless CMS, file storage, …) to your CI engine using webhooks for instance, so that each time your content changes, a CI pipeline is triggered, thus rebuilding all your website and invalidating the cache.

Moreover, new SSG such as Gatsby or Gridsome are build around React/Vue frameworks, which means your static site will benefit from the framework architecture and ecosystem, and once your page is initially loaded, additional DOM interaction is handled by your code using the framework.

The benefits of using a Static Site Generator instead of a Single Page App are:

• Better SEO: since your website consists of multiple HTML pages, bot crawling is easier and your content will be indexed nicely.
• Better performance: Modern SSG tools include only the necessary JS/CSS code to run the requested page, and will load additional code if the user navigate your website.
• Content decoupling: SSG provide a way to decouple your content from its representation.
• Multiple source content: SSGs provide multiple content source integration, such as headless CMS (Contentful, Strapi), local markup files or remote files.

This comes as usual with some drawbacks and limitations:

• User customized content: Static generation of content only work if the content pages are the same for all users, otherwise you would need to generate each page, for each user, which would take a lot of space and could lead to security issues, as all you static pages are public.
  So for user customized content (dashboard, forum posts, inbox, …), you will need to make API calls to get your formatted content.
• Learning curve: each SSG comes with opinionated ways of querying your content and generating your pages. Gatsby, even though React-based, is using GraphQL for content querying, so you will need to dive into it to make it work.
• CI overhead and preview latency: if you want your website to always be up to date with your content, you should plug webhooks and CI pipeline to make it work. If your pipeline takes 5 minutes to run, that’s as long you will have to wait to see your website updated with your content.

To conclude, I would say Static Site Generator are a great alternative to Single Page Apps if you care about SEO and if your website is heavy with public content. It is also a good alternative to classic CMS if you care about performance and developer experience.

Server-Side Rendering

The latest trend we will mention here is Server-Side Rendering. Historically, Server-side Rendering (or scripting) has been around for a long time.

<div>Hello <?php echo 'world'; ?></div>

Remember those wicked lines ? This is Server-side rendering at it’s worst. So SSR simply means rendering your HTML content from the server. JEE, ASP.Net, PHP Symfony, Ruby on Rails, all those regular MVC frameworks offer some kind of server-side rendering with templating engines.

But those server based rendering have limitations: you cannot handle client interaction with it, you’re limited to the initial content that will be displayed in the browser. Any following behaviors must be coded in additional JavaScript files.

When we talk about SSR in the JavaScript world, what we really mean in JavaScript isomorphic rendering. With the advent of NodeJS, JavaScript can now run both in the server and the client, which makes sharing rendering logic possible.

So what NextJS, Nuxt and the others offer are a way to share the rendering logic of your components, between the initial load from the server and the following interactions in the client.

You might be asking what are the differences with modern SSG like Gatsby ? Indeed, they too render the page in React and let the framework handle client-side interactions. Yes, but with SSR your pages are rendered at run time for each request, which mean you can customize the initial render of your page based on your user context. Whereas with Gatsby generated pages are static, thus the initial content is the same for all users.

Let’s sum up why one would use SSR and what benefits you could get from it:

• SEO: if you want user customized pages to be indexed on search engine or thumbnail preloaded on social media sharing, you need those pages to be server-side rendered.
• Content update: if your content sits in a CMS and you want every updates to reflect instantly on your website, SSR is what you need.
• Performance: as with SSG, SSR usually implies better performance that SPA, at least for the first time to load the page content.
• Back and front in the same codebase: Since SSR runs on your server, you can also host your API with it, having a single repository for your API and your front-end.

As usual, this comes with limitations and tricky sides:

• A server is needed: for SSR to work, you will need a server. Although some magical hosting platforms like Vercel will make use of serverless functions to do the pre-rendering, thus removing the need of a server.
• Performance: Yes, the initial load of the page will contain the content, but it is computed by a server, and servers can be bloated. Contrary to SSG which serves static files, with SSR you will need to make sure your initial loads is fast enough.
• Learning curve: For the isomorphic JavaScript to work, frameworks enforce conventions on the way you create your components. You have to learn and understand them before using them proficiently .
• Not really universal: Even though on paper, JavaScript can be used both in server and client, there are differences between the 2 environments. For instance, windowdoes not exist on the server, so you will need some “pragma” like code to make sure some of your front dependencies still work fine

The JAMStack

JAMStack is more of a marketing world. It means JavaScript, APIs and markup. So historically, it would mostly promote the usage of static site generators as an alternative to traditional CMS (Wordpress) or traditional Server-side MVC Frameworks.

With time this term brought together all the ecosystem and tooling linked to static and server-side rendered website, such as:

• CI pipelines
• Git integrations
• CDN for caching and geographical performance
• Cache invalidation
• Cloud functions for APIs
• … and much more every day

Alright, so what should I use ?

First of all, congratulations on making it through this heavy article. If you skipped to this part, I would understand.

When I start a front project from scratch, I’ll go through this decision diagram to know what technology I should focus on.

I hope this will help with your decision on your next project. Please share your comment if you feel I missed a point, or if you want to share your decision process and specific tooling with the community.

PS: NextJS handles automatic static optimizations, which means this framework can handle both static page generation and server-side rendering if needed. So when in doubt, it is a safe choice.