Consider the Jamstack for Your Next Solo Project

If you are a solo-builder I encourage you to consider a Jamstack architecture for your next project.

I have used the OG JAMstack for a few of my recent projects and it has been a delight. Less complexity, free deployments, ultra-fast website speed, zero performance concerns, close to 100% uptime, little configuration, no server management, and barely any need to monitor site health.

Jamstack has been a key that unlocked my ability to build and run multiple small websites. But until about a year ago I did not even know about this architectural approach to building websites.

If you are like me, or if you have yet to try Jamstack, this post is for you.

What is Jamstack?

The definition according to Jamstack.org:

Jamstack is an architectural approach that decouples the web experience layer from data and business logic, improving flexibility, scalability, performance, and maintainability.

Jamstack removes the need for business logic to dictate the web experience.

It enables a composable architecture for the web where custom logic and 3rd party services are consumed through APIs.

... which means?

I'm not sure.

I only discovered this definition as I started reading up on Jamstack for the post you are currently reading. The definition I was operating from was:

JavaScript, APIs, and Markup.

Hence the original name JAMstack. However, it appears the definition has evolved since its original inception¹. From JavaScript, APIs, and Markup to three paragraphs explaining some vague idea about decoupling and composability.

From JAMstack to Jamstack.

I can respect the need for a broader definition than one so specific it dictates actual languages to use (JavaScript and Markup). The ideas behind Jamstack can be achieved without the specific tools described in the original JAMstack.

But I think something is lost in this new definition.

My Jam

I'm a solo builder. I build small projects. Often without user logins or any personalized data. Sometimes without any user interactions at all. I build websites with small backends - sometimes with no backends at all.

For many of these projects, the key Jamstack ingredient has been the ethos of doing more at build time. Best case: doing all the work at build time.

My blog does not need to do anything at runtime except serve precompiled html pages requested by the user. Yet that is what a lot of blogs (mine included) did not so long ago (and still many WordPress sites do to this day).

A lot of websites have a lot of functionality that can be served by static assets. And even in the case of more dynamic requirements, techniques such as Incremental Static Regeneration and On-demand Revalidation can make "static" pages quite dynamic.

For me this is the Jamstack.

Salma Alam-Naylor's take on the Jamstack definition is more aligned with what I have experienced. For me the important part is:

Jamstack is an architectural model centred on serving pre-generated, highly portable static assets from web development platforms, usually via a Content Delivery Network (CDN).

One of my recent projects pulls data from a 3rd party API and visualizes it on a simple web page. I could create a backend that handles the data fetching (API token, formatting, error handling, etc.) and then call this backend from the client. And the benefit of that would be fresh data always.

But the use case does not require fresh data. 30 minutes stale data is just fine. And the API call is slow and rate-limited. So instead I call the API at build time, pre-compile the entire website and deploy it every 30 minutes. The result is a blazing fast website with a great user experience and tolerable data staleness.

Jamstack beyond the JAM

One of the ways the Jamstack has evolved is the popular combination of Headless Content Management Systems (CMS) and Static Site Generators. A site generator can fetch content from a CMS at build time and compile it into a static website.

The example illustrates the two modern Jamstack definitions we have looked at in action - decoupling the web experience layer from data and business logic, and serving pre-generated static assets.

I believe this is a good model of the Jamstack. Now let's dive into what it means for solo builders and small projects.

My Jamstack for small projects

I'm no expert and I have not extensively researched the different Jamstack options. This is just what I use.

Static Websites and Blogs

My blog is built with Astro, a framework for content-focused websites. It's the first time I try the framework so I don't have much experience with it. But so far so good.

Previously I have used Jekyll for blogging and it has served me well for simple blogs and static websites. Jekyll is a static site generator that relies on Markdown, Liquid, HTML, and CSS. Which means no JavaScript -- a Jamstack without the J. With GitHub Pages you can even host Jekyll sites directly from your repository.²

Other Projects

For other projects I use (and love) NextJs. NextJs supports multiple data fetching options:

• Client-side (CSR)
• Server-side (SSR)
• Static generation (SSG)
• Incremental Static Regeneration (ISR)

Which makes NextJs a Jamstack+ framework - I can use static generation for some pages and client/server side where static is not suitable. This makes NextJs very flexible as it is not just a Jamstack but a full-fledged React framework with everything you could ask for.

An even more advanced setup can use SWR to get stale-while-revalidate client side caching behavior with static pre-generated default data. Fast response with the ability to easily update any dynamic data from the client.

When and when not to Jamstack?

I think the Jamstack is especially powerful for solo builders. Going solo means less ambitious websites. For these websites the Jamstack toolkit is often sufficient. And when it is, the benefits are immense.

But there are also websites that should not be built on the Jamstack. Single-page applications have their use cases. So do highly dynamic pages.

Static pages can quickly fall short when working with e.g., personalized or frequently updated data. However, even pages that update regularly can be built as Jamstack pages and receive many of the benefits.

One example I like is this Static Tweet Demo by Vercel. Tweets are dynamic - the number of people commenting/liking/retweeting is constantly changing. But do you always need to show the latest numbers or can you live with slightly stale data?

In many use cases you probably can. The important part of a Tweet is often the text, not the exact number of likes at this very moment. So in many cases it is probably better for the user experience to load a faster but stale tweet rather than waiting for the latest data to arrive before loading anything.

Substack seems to agree with me on this one. If you look at Tweets embedded in their newsletters you will notice that they do not use the Twitter Embedded Tweet scripts but instead have what very much looks like pre-compiled newsletters, tweets included (which I understand as the Twitter tools are not great for user experience).

Jamstack is not an all-or-nothing proposal. Some frameworks only support static generations but many of them are more flexible. You can mix and match your website. Pre-compile some data sources and fetch others on the fly.

Consider what you are building and chose your architecture accordingly.

---

1. You can see the inception in a presentation by Matt Biilmann called "The new front-end stack: JavaScript, APIs and Markup" if you scroll down on the Jamstack.org page. ↩

2. I started out using GitHub Pages to host my Jekyll pages but moved to other free solutions as GitHub Pages have some limitations such as only supporting a limited set of plugins. There are lots of free options for static sites with more flexibility than GitHub Pages and they are all quite easy to set up. So I would probably encourage that if you need anything but a very simple static site. ↩