Introduction to the Jamstack: Build Secure, High-Performance Sites

Every so often, web development takes a dramatic turn for the better. In this article, we introduce the Jamstack, explaining what it is and why it’s great.

Back in the day, dynamic sites exploded with the LAMP stack. Then the MEAN stack provided a foundation for the next generation of web apps. Now that APIs and reusable components are on the rise, static sites are fashionable again. It’s a “back to basics” of sorts — but not quite.

Key Takeaways

• The Jamstack is a modern web development architecture that aids in creating faster, more secure websites that scale better. It stands for JavaScript (J), APIs (A), and Markup (M), and is a way of working that has been a revelation for many developers around the world.
• Jamstack can be used to transform dynamic sites into static ones, which can result in significant speed gains, improved security, and better SEO. This can be achieved by using a static site generator to create posts and pages, synchronizing the static content with a repository, and automating a deployment pipeline.
• Compared to traditional full-stack development, Jamstack utilizes global deployments to CDNs, automated pipelines, and pre-rendered pages for speed. It also allows for the decoupling of front and back end through APIs and microservices, and uses a single stack – JavaScript.

What Is the Jamstack?

Provided: Netlify

The Jamstack is a redefinition of the modern web for faster and more secure websites. These sites scale better and, with the proper toolset, are a lot easier (and more fun) to develop and maintain.

Let’s break up the term:

• J stands for JavaScript. JS has come a long way since it was introduced by Netscape in 1995. With reactive and progressive libraries, you can design web apps that behave pretty much like mobile ones.
• A stands for APIs. You don’t need to program every single functionality yourself, but can rely on third-party processing for a huge number of tasks.
• M stands for Markup. You can reuse components that have already been developed, or create new ones that are a lot easier to maintain.

Isn’t that just buzz?

In a way, yes. The term Jamstack, originally stylized as JAMstack, was coined by the company Netlify as a way of promoting their “all-in-one platform for automating modern web projects.” The principles behind the Jamstack aren’t really new, as web components and APIs have existed for quite some time.

But in very much the same way the term Ajax (asynchronous JavaScript and XML) was coined by another company back in the day — Adaptive Path — and even though the XMLHttpRequest (XHR) API that made Ajax possible also existed for some time, both Ajax and JAMstack were a refreshing revamp of ideas with legitimate uses that were quickly adopted by the community. The hype is well-deserved: this way of working has been a revelation for many developers around the world.

Static sites?

“Static sites” are the antithesis of “dynamic websites”, right? So how to provide rich and dynamic interaction with just plain HTML files? Well, JavaScript.

JavaScript has evolved a lot since the first browser wars, having consolidated itself as a general-purpose programming language with the advent of Node.js, and with libraries like React, Angular and Vue.js. The possibilities for designing high-grade user interfaces (UI) are endless.

Of course, JavaScript isn’t a silver bullet. You most probably won’t be doing data analysis or AI with it. But for web development, there’s hardly anything that you can’t do with an API that you can consume with JavaScript methods, as chances are that somebody already created a microservice for it.

And if, on top of that, you could “encapsulate” all of that process with markup into a reusable component — which you could pretty much drop-in whenever you need that specific functionality — you could potentially save hours of work every time.

That’s the J·A·M stack right there: JavaScript, APIs, markup.

Decoupled, Headless, Microservices, Serverless… Sorry, What?

All of these are hot topics in web development, and they’re all closely related but not quite the same. You’ll hear these terms a lot, so let’s clarify some terminology right form the start.

Coupled vs. Decoupled vs. Headless

COUPLED is when the content of a website is created, managed, and stored on the site’s back end, where the database lies (such as the WordPress admin). This content is then pulled from the back end and represented in the browser through a front-end interface (such as a WordPress template). In a way, a “coupled” application is the traditional “full-stack” with the back-end and front-end being different sides of the same app.

In contrast, DECOUPLED is when the back end and the front end are managed separately — meaning that the database and management tools will be on one server, and the front-end somewhere else. Naturally, there needs to be a medium by which both are connected, which is normally an API. What’s more, since the back-end now is effectively separated from the front end, there could be, in fact, several front ends in different locations! (Think of different storefronts using the same engine, such as Shopify.)

In a nutshell, HEADLESS software simply doesn’t have a front-end or a presentation layer. A headless CMS, for example, is one that could generate static content and push it anywhere: a mobile app, an Internet of Things device, a static website. Admittedly, this is also a “decoupled” situation, but here you might not even need an API. Think of a WordPress engine that exported its posts to be served as static HTML files: that’s headless. In fact, you’re on a page that was generated in exactly this way right now.

Monolithic (Tightly Coupled) vs. Microservices (Loosely Coupled)

Put simply, MONOLITHIC could be defined as software that’s built in one piece. Examples might include a mobile app, most applications that you can install on your computer, and web apps such as WordPress. These apps can still have internal “modules” or “components”, but we say these are tightly coupled because they’re an indispensable part of the application, without which the application wouldn’t work.

On the other hand, LOOSELY COUPLED software components work more like plugins that can be removed or replaced, and maybe the functionality will change but the core of the application will still work. This principle enables the “outsource” of functionality through third-party APIs — often called “microservices” — as they provide secondary features (image resizing, login, storing) that aren’t in and of themselves an indispensable part of the application.

Serverless vs. Traditional Computing

Admittedly, “serverless” is something of a misnomer. Whichever computing venture you’re in, there are going to be servers involved. But the way in which you access and manage the severs can be radically different.

In the TRADITIONAL MODEL, you may have an actual physical server (sometimes referred as a bare metal), or a virtual private server where resources are allocated for you — among other users — on a physical server. The resources are limited and, whether you use the 100% of them or not, you’re paying for them as if you do.

In the SERVERLESS MODEL there’s a huge pool of resources offered by many servers all connected between each other. You can just pull what you need when you need it, and scale (up and down) on demand. You can’t really pinpoint any physical server as yours — all you know is that the resources are there regardless of where they come from.

Traditional model	Serverless model
Physical servers with limited resources	A pool of unlimited resources
Prone to malfunctions (i.e. hard disk failure)	More reliable architecture*
Limited scalability	Unlimited scalability
Pay for all, including idle services	Pay for what you use (pay as–you–go)
Straightforward use	Need to learn implementation

*Notice that hard disks, CPUs and memory chip failures will still happen. But since resources are assigned transparently, you won’t even notice when hardware breaks and gets replaced.

Practical Examples of the Jamstack

That was a lot to take in, especially if you’re new to these ideas. So, let’s take a theory break and see some practical real-life Jamstack uses.

Case Study 1: Turning WordPress into a static site for a 10x gain in speed

If static is the way to go, then what better than taking a dynamic WordPress (WP) blog and making it into a static one? By doing so, we’ll reduce page load speed and latency by at least one factor, highly enhance security, and improve our SEO while at it.

The process, in a nutshell

1. Use a static site generator (SSG) to create posts and pages out of WP but in static format (text, Markdown, HTML).
2. Synchronize the static content with a repository on GitHub, GitLab or Bitbucket.
3. Automate a deployment pipeline so that every time there’s a change in the repository, changes go live instantly to a global CDN.
4. Relax and enjoy free hosting for secure and fast websites with automated deployments. 😎

But what about…

Of course, this generates a lot of questions:

• What about the admin?
• What about the categories and the RSS feed?
• How do I manage content now?
• How about the comments sections, and the newsletter?

At this point, you could kiss WP Admin goodbye, as from now on you’ll be generating content with a SSG. In fact, SSGs such as Jekyll are specifically designed for building blogs, and SSGs like Gatsby.js already come with all batteries included.

Managing content (such as modifying existing posts) is where a headless CMS comes to the rescue. For comments and newsletters, aren’t you already using an external API for those, such as Disqus and Mailchimp?

How do you actually do it?

We can’t cover the ins and outs of SSGs and headless CMSs here, but stay tuned for a future instalment of this series. We’ll present a step-by-step guide to migrating a WordPress site.

Case Study 2: Hosting static sites for free with an automated pipeline

“Free” is something you’ll hear a lot in the Jamstack community — and thankfully, it’s not free as in you still have to tell us your credit card number free.

The process, in a nutshell

In this case, we’ll take our static site (for example, the blog we migrated in Case Study 1) and put it online:

1. Set a GitHub, GitLab or Bitbucket repository.
2. Deploy to Netlify, GitLab Pages, or GitHub Pages.

At that point, every change on the repository will automatically trigger a new deployment (via webhooks), which could very elegantly be rolled back, should a problem occur.

Why do companies do this for free?

The overhead of dropping HTML files onto an already-deployed CDN is minimal. Remember, there’s no actual computing involved, no PHP rendering. Unless you host a massively popular site that eats up a lot of bandwidth, companies don’t mind giving out some hosting. And doing so can be good publicity for them.

By giving away lots of freebies, companies also lock you in. By the time you need a premium service (and if your business grows, you will), you’re already with them. That’s only fair — and besides, at that point you were already going to need to either develop an ad-hoc solution to your problem or pay for a service anyway.

How do you actually do it?

Both cases, Netlify or GitHub/GitLab, are very straightforward and require minimal effort. (Nevertheless, we’ll cover the process in detail in a coming article.)

How the Jamstack Compares to Full-stack Development

Let’s see how this novel approach compares to a LAMP or MEAN stack:

LAMP/MEAN stack	Jamstack
Web servers running sites	Global deployments to CDNs
FTP/SSH uploads, server restarts	Automated pipelines
Pages rendered at runtime	Pages pre-rendered for speed
Monolithic apps (e.g. WordPress)	APIs and microservices (front/back end decoupled)
Full-stack (front- and back-end languages)	A single stack (“JavaScript everywhere”)

What Else Can You Do with the Jamstack?

Hopefully at this point you understand the benefits of making your site. But perhaps you’re still skeptical about how to do the most basic things without back-end processing, such as user login and managing or storing dynamic content without a relational database (RDBMS).

Here are a few more examples of things you can do with the Jamstack:

• implementing a serverless database with a static site
• identity as a service (IDaaS): stateless authentication
• headless content management systems
• using serverless functions in static sites
• management of multi-purpose forms
• handle multi-platform notifications
• headless shopping carts
• reactive search

Conclusion

It’s inevitable that things evolve, especially in IT. Before it was the LAMP stack and then it was the MEAN stack. Now it’s the Jamstack, and in five to ten years it’s going to be something else. It’s best to embrace these changes and make them ours!

Learning new ways of doing things can sound like a hassle, but it can also reinvigorate your excitement for development. You may discover you spend less time maintaining servers and worrying about security issues. You may find that development takes less effort, and your clients are happier. And you may even become more competitive (and able to ask for a raise) as result. 😀

Jamstack Foundations

Keep an eye out for more articles on this topic. While we’ve covered Jamstack over the years, it has become a discipline and practice of its own. We’ll bring you the tutorials you need to become a Jamstack pro, and update our index here on this page. You can also stay up-to-date with our RSS feed or on social media.

Jamstack Fundamentals

• Introduction to the Jamstack: Build Secure, High-Performance Sites
• Jamstack Tools, APIs & Services: A Comprehensive Comparison
• How to Host Static Sites for Free with an Automated Pipeline
• How to Migrate from WordPress to a Static Site Generator

Jamstack Tools

• Getting Started with Gatsby: Build Your First Static Site
• Getting Started with Eleventy

And a whole lot more in the works.

FAQs About Jamstack