Thread by @oliverjumpertz

Let's take a look at the Jamstack,

the architectural approach that makes your websites faster, safer, cheaper, and all that with a better developer experience.

🧵🔽

1️⃣ What Is It?

The Jamstack is an architectural approach.

The letters "J A M" are an acronym and actually stand for:

▶️ JavaScript
▶️ APIs
▶️ Markup

🟢 JavaScript

JavaScript is the universal runtime of the web. Every browser can handle JavaScript and it's the language that brings interactivity to every modern-day browser.

JavaScript can either be written directly or act as a compile target.

🟢 APIs

More and more APIs are created every day. Take Stripe for example. They offer an API to process payments for you. It is designed to be integrated into other projects and doesn't offer a fully-fledged frontend like Paypal does, for example.

🟢 Markup

The web is made up of markup. HTML is THE markup language of the web. Every website contains HTML that is rendered by a client's browser. Without HTML there wouldn't be websites.

Next to its basic building blocks, the Jamstack embraces a few core principles, some of which are:

▶️ pre-rendering
▶️ decoupling
▶️ (Nearly) everything lives in git

🟢  Pre-Rendering

Traditional approaches work as follows (approx.):

Your browser sends a request to a server. The server fetches data from multiple data sources and starts rendering HTML from a template while filling in the data. It then sends back an HTML document which ...

... your browser parses. If it encounters additional resources like stylesheets, JavaScript, and images, it sends more requests to the server and fetches that data, as well.

When everything is fetched (at the latest) your browser can finally render the full page.

Although it doesn't take into account that some resources can be fetched asynchronously while the rendering already takes place. This pretty much sums up traditional approaches.

The Jamstack optimizes this process by moving some time-intensive tasks from the run time to the ...

build time. Instead of fetching data each and every time a user sends a request, the data is fetched once, at build time. This data is then rendered into a static HTML page which, once deployed, can be served to each and every user requesting it.

🟢 Decoupling

Traditional approaches have tightly coupled stacks. To actually be able to create HTML at runtime, you need business logic and logic which accesses the database. This creates a relatively tight coupling.

This approach also resulted in the creation of the full-stack developer. A developer that can build such an application and write frontend, as well as backend logic.

When built with the Jamstack, the project focuses on the frontend. It is a fully separate application ...

... that accesses already existing APIs and data sources. It puts the focus on the frontend work while optimizing the outcome heavily.

And what's served later is served as fast as possible. A benefit for users and search engines. Both value speed pretty high these days.

🟢 (Nearly) everything lives in git

Git is one of the (if not the) most-used version control management tool(s) in the world. Most source code is already tracked by git and enables atomic deployments from a tag or a commit hash.

Adding your website's data to it simply makes sense. One commit does not only contain the structure and functionality of your website at one certain point in time, it does now also contain its state and content.

A commit now contains the one article you published under this ...

... hash, and when you go back one commit, this article is gone again. If you wanted to revert your page to this exact state, you can simply revert the state of your git repository.

This streamlines the process by a lot. No more reverting git state, ...

... then reverting the database, and so on...git is the only master of truth.

A change in your repository triggers a new build. This build, when finished, leads to static files. Those are uploaded to the content delivery network which invalidates its caches ...

... and then serves the updated version.

2️⃣ How Does It Work?

You've already read about some of the principles of the Jamstack, but to give you a sum-up of how it works:

Sites are pre-rendered by a static site generator. At build time, data is fetched from multiple sources and rendered directly into static pages.

Assets like images and resources like JavaScript are optimized and placed into the HTML document. The static files are then usually deployed to a content delivery network that keeps your site as close as possible (geographically) to the user while also leveraging caching.

At runtime, existing APIs can be used to enrich the overall user-experience. This means that features like commenting on articles, making a payment, or liking a post can still be handled dynamically at runtime, but everything that can be served statically otherwise, ...

... is served statically to reap the benefits of increased speed, ease of use, and so on.

3️⃣ Conclusion

The Jamstack is an interesting approach. Its concepts aren't new but due to the rise of the cloud and content delivery networks in recent years, many of them actually became possible on a large scale.

There are many service providers nowadays, that give you the basic infrastructure building blocks to base your net Jamstack project on. Netlify, Vercel, even AWS. These are only some names of larger players in this field.

Frameworks like Next and Gatsby or tools like Hugo streamline the experience for developers and let you use the skills you already have to get building.

So, are you already using the Jamstack? Do you plan to use it? What do you think?