The JAMstack is a formalisation of current practices around static sites being lead by Netlify, in the same way Heroku championed the 12 factor app. It may be in their business interests to push a formalisation, but that's no reason to discount the idea. On examination there's much to like about the JAMstack.
There are three distinctive features of a JAMstack application.
The first is the use of client side JavaScript for any and all dynamic programming on the client, such as changing routes and loading a new page and adding interactivity.
The second is the use of API’s. Server-side processes and database actions are abstracted into reusable API’s that are accessed on the client over HTTP/S with JavaScript.
Finally the site is rendered down to markup which is sent out to a server, often a CDN. In this case, the backend server only serves markup. It's not dynamic. This is where the speed of the JAMstack comes from. You cannot get any faster than shipping pre-rendered markup.
The JAMstack is a very different way to create and deploy websites. Depending on how many (if any) websites you have created, worked on or deployed in the past, the true beauty of this setup might not be obvious.
Let’s look at the biggest paradigm shift compared to the traditional method of building websites (which does still have many valid use cases).
In the past when you visited a website, your request was routed to a server. That server then evaluates your request; it works out you want. Let’s say it's a webpage with some information on it.
Next the server pulls in some data from its database, sends that down to a theming function, which itself grabs some of its own data in the form of templates. The theming function them shoves the data from the database into its theme, and sends that back to the client as HTML.
This whole process can be quite fast. But most of us don’t do it like that. If you’re running a Wordpress or Drupal site, you’ll likely have a bunch of modules installed to provide extra functionality. Depending on the request each of these will fire up and do something, adding time to the request.
In short, when you request a page the server builds it for you. This doesn’t scale super well, so we add caching services in front and around the website. Now, if you request a page that someone else requested a few minutes ago, the server grabs it from its cache instead of rebuilding it.
But think about it. We don’t need all of that stuff.
The software engineering world has moved a long way since the hay-days of Drupal and Wordpress.
So has the information security world. So far in fact, that deploying a CMS without an update and maintenance plan actively in place, is playing Russian Roulette with your site and possibly your reputation.
This is why I love the concept of the JAMstack.
Think about all the potential vulnerability areas that exist in your stack. Think about the performance issues.
What if you could just chuck all that code out?
Instead of compiling on request, we compile the entire site when the content is changed.
This is where JAMstack diverges from the static site produced by the likes of Jekyll. A modern JAMstack website is defined as much by its interactivity as it is static. In reality JAMstack is just a cool name to rally a bunch of related and converging technologies around — but don’t underestimate the power of good branding.
A JAMstack’s power comes primarily from its speed. Just like a static site, by compiling the HTML for the entire site ahead of time, none is lost when someone requests a page. When they request a page, we can send the HTML straight back to them. When their browser gets the HTML it will also pull down the CSS, images and most importantly our client side JavaScript. At this point we can start enriching the page with more information that did not exist in the initial HTML.
Let’s take a step back.
If our top priority is speed (which is always should be), then getting a visual rendering of the page in the shortest time possible is the goal. You don’t need to send the entire page for that to happen. If your site is anything like this one, you might not even need this. However if you’re shipping something more complex, you can gain great speed improvements by only sending down enough HTML and CSS to get a page rendered.
If this sounds familiar, it’s because they are essentially Progressive Web Apps (PWA).
Now you can’t do a PWA without an API. By definition you’re enhancing the user experience on the client. This is another point where the JAMstack diverges from a traditional static site.
The API could be as simple as pulling in more content, or pulling in authentication information from another (possibly third-party) service.
Search is still an early area for the JAMstack, however there are a number of third party services that do a great job of solving this problem.
But what about the data?
This is where in my opinion it gets the most interesting. If we compile the site each time the content changes, how do we know when the content has changed?
Its simple really, like the static site generators we store the content in the same code repository as the code that builds the website, and runs the API’s.
Typically stored as markdown, the content files live in a top level folder called content. Liberal use of front matter with markdown files, or using JSON files can provide you will all the custom fields you could ever want.
You do lose functionality over a tradition CMS here. But I’d suggest for almost all use cases, a change in workflow is all that’s needed. For example, if you have a content type with an extensive set of fields, its possible to get one wrong. With a reliable review step in the publishing workflow however, this should be a non-issue.
If you really do need a CMS there are some Content as a Service (CaaS) options that can be integrated with your JAMstack. There's also netlify-cms which looks promising.
Typically a deployment of the JAMstack is centered around a git repository, and a continuous deployment system. This does necessarily require some training for content editors in how to use git. What you gain in this process though, is versioned content, and no external state to manage.
To break this down, when deploying a site you typically have two categories to watch. That with state, and that without. A database is state, the webserver generally is not. A quick test to work out if your service has state in it is the following:
Can you terminate the service and create a new one without losing data?
If you ponder that potential consequences of getting that question wrong, you’re on your way to understanding the challenge of properly managing state in deployed applications.
State needs extra care. Unless you're using a NoSQL database, your database is likely on one server. In both cases you need to manage that server and it's backups.
With a stateless server you can be incredbily cavaliar, with a statefull server you really can't.
But what if you didn’t have to worry about state?
With the JAMstack you can store your content in your code repository, or on someone elses service. But we render it down to markdown and ship that to our servers. If you use an external server for your state and it goes down, you'll be the only one to know. It won't affect the live version of your site.
This is where you’ll find your first hurdle though, the quickest time you can change your content on your live website is equal to the full build and deployment time of your site. Like all the tradeoffs with the JAMstack, you need to consider if this is something you can accept.
You might think this rules out fast changing news sites, but possibly not. You can have some dynamic content on the JAMstack. Perhaps you load the markup, and change it if you get a repsonse back from an API server.
This is all great, but I still need a server right?
Kind of. You need a backend server to respond to the API requests for new content, and to serve the pages. Depending on how clever you get, your API requests can be precompiled ahead of time, and stored as JSON files too.
The two obvious choices right now are GitHub Pages, and Netlify. The first is hopefully reasonably well known and understood. Essentially you can get Github to serve static content from a docs folder in your repository or a special branch names gh-pages.
Netlify is similar, with the key difference being that they ship your compiled app out onto their CDN, making it insanely fast from bascially everywhere in the world.
If you go with the JAMstack, you’re pushing all the dynamic programming onto the client. You need to be familiar with modern front end build tools, and possibly a front end UI framework like React. You need to invest time into a build pipeline for Continuous Deployment. But you don’t have to setup or manage any servers.
You can use something like Phenomic or Hugo, with Travis CI, Circle CI, or any of the other CI services. And ship that to GitHub Pages or Netlify.
With the JAMstack you no longer need to manage a database, or deployed state as we traditionally do. Your backup can now be distributed with your git repository — setup a couple of mirrors if you want.
You’ll get an insanely fast site.
But, you still need to solve interactivity, things like search and so on.
The JAMstack looks like the confluence of front end build tools, modern development practices converging into a new way of doing things.
JAMstack is not for every site, there’s plenty of web apps that just don’t fit. But if you’re site comes close, it might be a concept worth exploring.