A History and Overview of the Jamstack

In 2018, Github co-founder and former CEO Tom Preston-Werner predicted that in the next five years, developers would be building their next “large scale, fully featured web app” with the Jamstack. 

So far, he’s not wrong. In the last few years, Jamstack has become synonymous with modern web development. It’s everywhere. It’s a solution that’s scalable, atomic, and designed to be modular. But what is it, and where did it come from?

Jamstack stands for JavaScript, APIs, and Markup, a term coined by Mathias Biilmann, the co-founder of Netlify. In this approach to web development, a variety of tasks like authentication are outsourced to third-party APIs, and HTML/CSS markup is precompiled before deployment. This method focuses on the front-end build of a website, allowing for projects that don’t rely on server-side code. 

They’re not entirely serverless; Jamstack projects are served directly from a content delivery network (CDN), which is a system of distributed servers that delivers pages and other web content to a user.  But the Jamstack provides a different way of working with servers. It allows designers and developers with primarily front-end skills to harness tasks that are usually in the back end realm, such as saving and reading information from a database, validating data, and submitting data and requests.

How the web has changed

In the early stages of web development, browsers were basically a means of reading documents, and websites were a collection of HTML files in a folder exposed over HTTP by a web server. If a user submitted a form, commented on a blog, or essentially just interacted with a website, it required an entirely new page of HTML. Developers moved to dynamic rendering,  a model wherein a program on the server would build HTML for each site visit.

Prior to the rise of JavaScript and cross-domain web APIs, the internet provided a far less responsive web experience than what we know now.  The advent of asynchronous web applications using techniques like AJAX (aka “asynchronous JavaScript and XML”), have allowed for interactive user experiences that don't feel as though a server is constantly fetching data. The application is doing so in the background, because the data layer is decoupled from the presentation layer. 

The rise of single-page applications (SPAs) has given many websites the feel of a native app, allowing for a faster transition across the site, and has been adopted by JavaScript frameworks and libraries like React, AngularJS, and Vue.js. But there are a couple key disadvantages to SPAs, particularly search engine optimization and load time. SPAs are built on JavaScript, and data and content is downloaded upon request. This makes search engine optimization difficult, as individual “pages” don’t have their own URLs, and can’t be scanned by search bots. Another critique of SPAs is slower load time, especially as the application grows in size.

This led to a trend toward static sites began in 2008 with Jekyll, a static site generator (SSG), written in Ruby by Preston-Werner. SSGs take data and content and apply it to templates, and create a structure of static HTML markup files (and a view of a page) to deliver to a site’s viewers. 

In the past, when a visitor came to a website and created some type of request, a web server would have to do the same thing that SSGs do now. They would take content and data, apply some logic, throw it on a template, generate a page view, and deliver it to the user. However, as soon as a site becomes popular, there’s a risk that a web server might not be able to keep up with the increased demand.

The advantage of SSGs over SPAs is that instead of creating markup and page views upon request, SSGs do this at build time- far in advance- for every possible page view. That way, site performance isn’t affected by increased traffic, allowing developers to account for higher traffic levels well in advance of deployment. 

Jekyll has for years remained the top SSG in terms of brand recognition, largely due to it driving Github Pages, the Github feature that allows users to host websites based on their repositories for free. But the widespread use of JS frameworks and libraries- particularly React- have led to a rise in popularity for other generators like Gatsby and Next.js, which bring together the best of both SSGs and SPAs.

Next.js is capable of generating page views at request time or at build time. The current version allows for serverless functions, which is great for security, scalability, and affordability. But more on that later.

Gatsby is based on React and powered by GraphQL, and builds sites as static files that can be deployed on different services like Netlify, Vercel, AWS Amplify, Github Pages, and more. Data can be pulled in from headless CMSs, APIs, and is pulled in through GraphQL.

A challenge for SSGs is build time, especially when faced with the incremental build model, aka designing, testing, and implementing each piece incrementally. If your page views are completely built in advance, how do you then break off a small piece of it later to work on without having to rebuild everything else? 

Just over a month ago, Gatsby released incremental builds on Gatsby Cloud, which will only rebuild the necessary parts of a site when a change is made in a CMS.

APIs

Many companies require a variety of experiences, products, and features on their sites. This can include information about their business, a company blog, and an ecommerce store, among others. Using a traditional website architecture or structure, the front end of these applications is tied to the back end to generate it on the server. It’s an expensive way of doing things, and means that each piece of the site is intertwined, making it difficult for each developer working on it to specialize and focus their efforts on a single part.

With the Jamstack, sites are designed around multiple services provided by different APIs. Thanks to a broad ecosystem of ready-made APIs, developers can rely on them for everything from authentication to comments to ecommerce. Those API providers have their own teams, preventing front-end developers from having to run server-side code at request time, leading to a better experience for users and ops teams, and a better understanding of the projects they’re working on.

Of course, each service does come with its own particulars, and combining data across them can be a challenge that can slow down development. Currently in beta is TakeShape Mesh, a service that combines data from all services used in a Jamstack project into a GraphQL API.

How front-end development has evolved

CSS-Tricks creator Chris Coiyer puts front-end development best: it deals very directly with the browser, devices, and users. But with the rise of component-driven design, a multitude of APIs, and state management, the term has exploded to include much, much more than just HTML, CSS, and JavaScript. 

What the Jamstack does for web development is alleviate front-end developers’ reliance on server-side development by moving to a CDN. At last year’s Jamstack conference, Coiyer discussed how the move to serverless development has essentially enabled front-end developers to fully create sites from front to back. Again, serverless doesn’t literally mean  entirely operating without a server, but it provides a way to pay for and work with servers that’s cheaper than building your own.

Benefits

This blog would be impossible without referencing “Modern Web Development on the Jamstack,” written by Biilmann himself along with co-author Phil Hawksworth. In it, they outline several benefits to the Jamstack, which mainly arise from decoupling the front end from the back end.

The first benefit is that front-end developers gain the ability to focus their areas of expertise, rather than trying to be jacks of all trades, and masters of none. Brad Frost, the author of “Atomic Design,” has pointed out that there are front-end developers that deal with the “front of the front” and the “back of the front.” By decoupling the back end and the front end, front-end developers have the option of focusing on JavaScript and logic or user experience, rather than trying to do both. And separating APIs into smaller services means that gaining a deeper level of understanding of each one becomes much simpler.

The second benefit, as Biilmann and Hawksworth also argue, is that the Jamstack is a boon for financial savings, team efficiency, innovation, and scalability.

It’s not an easy task to anticipate how much traffic and use a website will get. In traditional web architecture, each page therefore has to be built with the capacity for high volumes of traffic, and that capacity has to be extended through each tier of the website build. This creates a need for multiple servers for databases, application servers, caching, and more. Each of these pieces of infrastructure has an associated financial cost. 

Nowadays, with cloud computing, it’s less common for all of the server-related costs to include a physical machine. Regardless, these pieces of infrastructure still add up. On top of that, many of these pieces also need to be duplicated to provide staging, testing, and development environments, in addition to the actual production build.

This is also tied to scalability. Jamstack applications benefit from a simpler architecture. The responsibility of scaling a Jamstack site falls on a CDN, which serves the site’s assets. CDNs can also help reduce hosting costs, by reducing the amount of data an origin server must provide.

CDNs also have other benefits, including speed and security. On the user side of things, CDNs distribute content closer to website visitors, meaning faster page loading times, and in turn, lower bounce rates and increased length of visits. They can also handle more traffic because of their distributed nature, and working serverless can improve security by distributing points of failure, and therefore mitigating distributed denial of service (DDOS) attacks. 

But even without a CDN, the hosting environment is still simplified. Because the process of accessing the content and data and then populating the page templates is decoupled from the requests for these pages, the demands on these parts of the infrastructure is not influential to the number of visitors to the site. Money is saved because large parts of traditional infrastructure don’t need to be scaled, or don’t exist at all.

Challenges ahead

The Jamstack still faces some obstacles to widespread adoption. 

Progressive web apps (PWAs) also pose an interesting challenge for the Jamstack. PWAs bring a native app-like experience to a browser, can be installed to a device’s home screen without having to go through an app store, and can be downloaded and used offline. They’re also more easily discoverable by users, because they benefit from search engine optimization like any other website, when compared to native apps. They use web APIs for capabilities like push notifications, and like most web apps, they follow design best-practices like responsive design and progressive enhancement.

When looking at SPAs or static sites, it’s easy to see the merits of the Jamstack. But PWAs can be slightly more dynamic. Jamstack detractors argue that building full applications with dynamic features can be an issue. Using an often-cited argument against the Jamstack, Jay Freestone of the agency Browser London, asserts that if more dynamic features are needed, developers are forced to create their own API (aka the same as creating a backend), or at the very least rely on third-party APIs, which he says can be fragile and simply spreads out responsibility.

It’s certainly possible to harness the power of the Jamstack to build a PWA that is both static and dynamic. Arkadiusz Górecki, a front-end developer at Bejamas.io, recently outlined how building a PWA with the Jamstack provided the expected benefits- scalability, performance, and a quick and affordable build. 

That being said, PWAs don’t yet have widespread adoption. Applying progressive enhancement to a solid foundation of a lightweight, speedy static site has been made simpler than ever, thanks to client-side frameworks like React, Angular, and Vue becoming more and more sophisticated.

Jamstack’s last obstacle, of course, is education, despite a huge surge in popularity. Netlify is approaching over 1 million developers using its platform, Gatsby is used in over 200,000 projects on Github, and Next.js is used in over 80,000. But there are now tons of resources from an ever-growing community, in addition to an array of documentation and best practices from official sources.

There are some great opportunities for further education on the topic. There are remote conferences like Backendless Conf and the Jamstack conference (the latter just took place, and their talks are up on YouTube). Free tutorials are also easy to find.

It’s had a meteoric rise, but the Jamstack hasn’t yet reached maturity. But just as CDNs have progressed to become more robust and accommodate the rise of “serverless” development, so too will the products meant to help the Jamstack become the future of web development.