Modern Web Development on the JAMstack

Introduction

In just the past few years, a flurry of advancements has greatly strengthened the web as a content and application platform. Browsers are much more powerful. JavaScript has matured. WebAssembly is on the horizon. It certainly feels like the beginning of a new chapter for the web. You’ve likely felt this as you’ve witnessed the explosion of new frontend frameworks and API-based services.

Although what’s technically possible in the browser has advanced, so too have expectations for immediacy. Videos must play instantly. Browser applications must launch faster than their desktop counterparts. Users have become increasingly mobile and increasingly impatient—we are all fed up with slow pages and we vote angrily against them with the back button. (Google also seems to be losing patience, and now factors site speed into its famous ranking algorithms.)

Broadly speaking, this book covers new, modern approaches to building websites that perform as fast as possible. More concretely, this book shows you how to run any web property, from simple sites to complex applications, on a global Content Delivery Network (CDN) and without a single web server. We introduce you to the JAMstack: a powerful new approach for deploying fast, highly scalable sites and applications that don’t require traditional frontend infrastructure. If you tend to feel delivering great websites should be more about the craft of markup and JavaScript than server setup and administration, you’ve found your book.

And, if you’ve ever struggled with any monolithic system or framework—wrestling with hosting, deploying changes, securing, and scaling everything—you already understand why the JAMstack is becoming so popular. It’s one of those rare shifts in the landscape that delivers a productivity boost for developers and a large performance boost for users. The JAMstack is helping to bring about a more secure, stable, and performant web that’s also more fun to develop and create for.

Under this new approach, there isn’t a “server environment” at all—at least not in the traditional sense. Instead, HTML is prerendered into static files, sites are served from a global CDN, and tasks that were once processed and managed server side are now performed via APIs and microservices.

We realize that seasoned web developers might eye anything new with quite a bit of skepticism. There have certainly been countless other new ideas on how to build the web before. For nearly three decades, the developer community has explored ways to make the web easier and faster to develop, more capable, more performant, and more secure.

At times, though, the effort has seemed to trade one goal for another. Wordpress, for example, became a revolution in making content easier to author—but anyone who’s scaled a high-traffic Wordpress site knows it also brings a whole set of new challenges in performance and security. Trading the simplicity of HTML files for database-powered content means facing the very real threats that sites might crash as they become popular or are hacked when nobody is watching closely.

And dynamically transforming content into HTML—each and every time it’s requested—takes quite a few compute cycles. To mitigate all the overhead, many web stacks have introduced intricate and clever caching schemes at almost every level, from the database on up. But these complex setups have often made the development process feel cumbersome and fragile. It can be difficult to get any work done on a site when you can’t get it running and testable on your own laptop. (Trust us, we know.)

All these challenges have led the developer community to begin exploring the JAMstack as a modern refactoring of the way websites are developed and served. And like any good refactoring, you’ll find that it both advances and simplifies the stack.

Being web developers ourselves, the authors of this book are more excited by the JAMstack than we’ve been about any emerging trend for quite a while. That’s because it uniquely solves for all these common problems—developer experience, performance, and security—all at the same time, and all without one compromising the other. To us, it feels like the logical future of the platform.

It just makes sense.

Developer Jonathan Prozzi said it best on Twitter: “My learning journey leading to #JAMstack has re-ignited my interest and passion for web technology.” We think the JAMstack can do a lot to rekindle your own enthusiasm, too, and we’re eager to welcome you to the growing community of JAMstack practitioners. You’ll find developing for the web has become fun and fearless all over again.

The JAM in JAMstack

The JAMstack brings together JavaScript, APIs, and markup, the three core components used to create sites that are both fast and highly dynamic. JAMstack sites are well suited to meet the demanding requirements of today’s mobile-first web (where load times urgently matter and quality bandwidth can never be guaranteed).

We should pause to say what the JAMstack isn’t: it’s not any one specific technology in and of itself; nor is it driven by a large company; nor is there any standards body that controls or defines it.

Instead, the JAMstack is a movement, a community collection of best practices and workflows that result in high-speed websites that are a pleasure to work on.

As you dive in, you’ll find a few common guidelines but also lots of choice, including your pick of languages. JavaScript is called out specifically as the language of the browser, but you can use as much or as little JavaScript as your project requires. Many JAMstack sites also use Python, Go, or Ruby for templating and logic. Lots of open source software has sprung up to help you create JAMstack sites, and we spend some time in this book going over a few of the more popular options.

Not everything about the JAMstack is a new idea, but it’s only very recently that we’ve had the technology required to make the approach possible, especially on the edge of the network and in browsers. This first section of the book should give you a working understanding of the JAMstack, why it’s an important new development, and how to reason about it.

A Workflow for Productivity and Performance

By nature, JAMstack sites are the following:

• Globally distributed and resilient to heavy traffic

• Centered around a developer friendly, Git-based workflow

• Designed modularly, consuming other services via APIs

• Prebuilt and optimized before being served

It’s this last point that deserves special attention. Think for a moment about today’s most common approach to serving web content: for each and every request made to a website, data is pulled from a database, rendered against a template, processed into HTML, and finally pushed across the network (and maybe even an ocean) to the browser that requested it.

When web servers repeatedly build each page for each request, it begins to feel like a lot of work happens in the wrong place at the wrong time. After all, a general rule for maximum performance is to perform the fewest steps possible. Shouldn’t new HTML be produced only when content or data changes, not every time it is requested?

As it turns out, that’s exactly how the JAMstack operates. Here’s what happens under the JAMstack workflow:

1. The source for the site is a hosted repository that stores content and code together as editable files.

2. Whenever a change made, a build process is triggered that prerenders the site, creating final HTML from templates, content, and data.

3. The prepared, rendered assets are published globally on a CDN, putting them as close to end users as physically possible.

This approach eliminates large amounts of server and network latency. Given the efficiency and simplicity of serving prerendered content directly from a CDN, it’s no surprise JAMstack sites tend to acheive the highest possible scores on speed tests like Google Lighthouse.

Globally distributed content isn’t entirely new, but the speed at which you can update CDN files directly from a repository is new. No more dreaded delays waiting for the CDN’s cache to expire—we can now build highly distributed sites right on the edge of the network and remove the need for any type of frontend servers to process each request.

Version Control and Atomic Deploys

In the JAMstack, it’s possible and common for the content of the site, blog posts and all, to live in a Git repository right alongside the code and templates. This means that no content database is required, making JAMstack sites dramatically easier to set up, run, deploy, branch, and modify.

And in this version-control-centric world of the JAMstack, every deploy of the site is atomic, making it trivial to roll back to any state, at any time, for any reason. Complex staging environments are no longer needed as previewing and testing changes use the branching system built into the heart of Git. With the workflow for changes made fast, simple, and safe, most JAMstack sites are far from “static” and are often updated just as often as their more complex counterparts, sometimes hundreds of times daily.

Contributing on the JAMstack

As you picture a JAMstack workflow, you probably imagine making code changes in an editor and then running a command to build the site and deploy it to production. Quite a bit of development on the JAMstack happens in this exact way, especially early on.

But for most JAMstack sites, the contributors aren’t just developers. New updates to the site are also triggered by content authors using a CMS as well as by automated actions, just as you’d expect from any modern website.

Instead of happening locally, the build process now often runs on a hosted service in the cloud. Push a change to GitHub (or another repository service) and a new build is automatically triggered on special-purpose build servers, sending the final result directly to the CDN. It’s an amazingly addictive way to develop, and we show you how to get it going.

But what about those authors who aren’t developers and might not be familiar with Git? The JAMstack has spawned a clever new generation of authoring tools that look and function like a normal Content Management System (CMS) but actually check changes into version control behind the scenes. In this way, everyone participates in the same workflow, enjoying the safety, branching, and rollbacks of modern version control software—even if they are unaware it’s happening. It’s a nice improvement over content requiring a database that you need to manage and version separately.

You also can contribute changes to the site in a third way: programmatically, via automation. For example, you can run a script daily that incorporates the latest press articles and Twitter mentions into the home page. Or take what happens on Smashing Magazine’s JAMstack site: each time a user comments on an article, a simple function commits the comment to the site’s repository and triggers a new build (as long the comment passes moderation).

Starting to see the power of this workflow? Developers, content authors, and automated processes are all saving a living history of the site right to the same place—the repository—which acts as one source of truth. Even if the site is updated hundreds of times in a day or more, every state is preserved. And, most important, the site stays fast and responsive because every page is built and optimized before being served.

APIs to Process and Personalize

It takes more than HTML, though: web applications need to perform work and have state. Traditionally, web servers were required to store a user’s session and allow the application to do things like remember items in a shopping cart or power the checkout experience.

In the JAMstack, these personalized experiences are done using JavaScript to make API calls that send and receive data. Many of the APIs used are third-party services. Stripe, for example, is a popular service for processing payments. Algolia is a popular API for powering search. (Your authors have a deep love for almost all technology, but would never go back to manually handling payments or running Apache Solr search clusters.)

Other APIs can be custom-built functions unique to each application. Instead of a monolithic and complex framework that manages everything, sites can now be designed around microservices: simple functions that perform specific tasks, executing once when called, and then exiting cleanly. It’s a very scalable approach that’s easy to reason about.

But with no servers to store user sessions, how do we connect all of these discrete API calls? How do we handle authentication and identity? To power user accounts, a JAMstack application will often create a secure ID token stored in the browser. (This type of token is called a JavaScript Web Token, or JWT.) The identity is then passed with each API call so that services are aware of the user. We cover this setup in more detail later, but we introduce it here to help you understand the power of the platform. JAMstack sites can do much more than serve simple content, and many are rich applications with all the features you’d expect, like ecommerce, membership, and rich personalization.

Static sites may be, well, static, but you’ll find that JAMstack sites are anything but. In fact, you’ll find prerendered markup for web UI combined with APIs and microservices to be one of the fastest and most reliable platforms available for advanced web applications.

Bringing It All Together: A Smashing Magazine Case Study

Smashing Magazine has been a steady presence in web development for more than a decade, running a massively popular website and publishing high-quality content covering themes like frontend development, design, user experience, and web performance.

At the end of 2017, Smashing Magazine completely rewrote and redesigned its site to switch from a system based on several traditional, monolithic applications to the JAMstack. This final section of the book showcases how it solved challenges like ecommerce, content management, commenting, subscriptions, and working with a JAMstack project at scale.

Ready? Time to Get Our JAM Session Started

The best way to learn the JAMstack is to dive right in. The JAMstack uses the skills that you already have but pushes on your conventions about how websites are run and what’s possible without servers. We suggest you bring the same open mind and sense of adventure that brought you to explore web development in the first place. There’s never been a better time to be a web developer—unburdening ourselves from administering websites is bringing the focus back to creating the content and interfaces that make them compelling.