What are the differences between JAMstack application and SPA

Question

This might be a silly question, but I'm just starting now in Web dev, and I am especially new in JAMStack.

I've been reading a bit, and from what I get, in JAMStack basically, we give everything to the frontend app so the Javascript can be like our OS and fetch everything through the API universe.

Although, this seems to me a bit like how SPAs work. We fetch what we want through APIs and re-render parts of the page accordingly.

What am I missing here? Can anyone point me in the right direction and make like a comparison of how these two differ and what are the advantages/disadvantages of such differences?

Thank you

Sleight

Answer 1

You're right, that it's confusing.

Previously, the term JAMstack described JavaScript, APIs, and Markup. Due to the adoption and confusion around this technology trend, jamstack.org slightly changed the definition from JAMstack to Jamstack.

Jamstack is an architecture designed to make the web faster, more secure, and easier to scale. It builds on many of the tools and workflows which developers love, and which bring maximum productivity. The core principles of pre-rendering, and decoupling, enable sites and applications to be delivered with greater confidence and resilience than ever before.

When you look at the old definition and think of it very purely, SPAs can fall under this category. This might be the reason while the definition was moved away from JAM (JavaScript, Apis, Markup) to Jam (a mix of tech).

What most people refer to as JAMstack sites, though, are sites that ship with prerendered HTML. And this is where the difference lies. JAMstack sites (or static sites) come with a build process in place that pre-generates all the needed HTML files. This approach is cheap to host, fast (a SPA has to make requests first to show something), and more accessible.

Popular projects are eleventy, or Nuxt and Next, Gatsby or others.

And even looking at the popular options there are nuances. Eleventy e.g. goes the "purist" way by shipping mainly pre-generated HTML.

Nuxt/Next/Gatsby and others usually ship with a universal JavaScript approach. They produce static HTML but once the JavaScript is loaded they transform into SPAs.

That all said, the nuance is subtle, and I wouldn't worry about it too much. But keep in mind that pre-rendered HTML sites in the JAMstack world offer some nice performance improvements compared to classical SPAs.

Torietorii

There's a lot of fuzz and inaccuracy around the definitions. Why is a Next classed as JAM but React is not? Are we just renaming SSR? "a SPA has to make requests first to show something" - obviously not every SPA does so, and when it does make a request, is that not just the API part? – Aswarm

seems like a term made up by marketers at netlify etc – Crane

It sounds like SSG? – Armoire

Answer 2

Good question. The J in the name Jamstack can easily lead to confusion in this area!

There's no prescription about what you use in the front-end for Jamstack site. It might be single page application with lots of JavaScript, or it might be purely HTML and CSS with no JavaScript at all.

The distinction is how it is served.

Jamstack sites are hosted as static assets rather than from a set of servers which actively compute the response to each request. This gives them some nice performance, scale, and security characteristics. And unlocks some pleasant development workflows

So, although an SPA might looks similar to some Jamstack sites in the front-end, it might be hosted on a server which actively generates responses to each request, applying content to templates etc, which the front end uses. Whereas a Jamstack site would serve pre-generated assets, perhaps enriching them client-side with JavaScript and calls to APIs.

I made a FreeCodeCamp video which details much of this (and then later digs much deeper into examples) which might be of interest, and there is also a glossary of some related terms on the Jamstack site.

Gabion