Markdown is Markup and Other Confusions Around JAMStack

Multiple times from multiple people I've heard the M in JAMStack described as standing for Markdown. It's an easy mistake to make, since static site generators have been so closely tied to Markdown for so long. Jekyll, for instance, has supported Markdown as the default way to create content pages going back to some of its earliest versions in 2009 and almost every other major static site generator today does the same. So if you know the history of the tools that the JAMStack is based upon, it makes sense to think the M is for Markdown.

M is for Markup

However, the M is actually for mark_up_. Markup is a much broader term that encompasses Markdown, which is a lightweight form of markup. There are other similar types of lightweight markup that some static site generator tools support including AsciiDoc and LaTeX. HTML is also markup (it's in the name after all - Hypertext Markup Language).

But Markup in the JAMStack sense is more than just Markdown or HTML. A key part of that is combining these markup languages with templating. So, for instance, Jekyll uses Liquid, Hugo uses Go Templating and many others use Handlebars or something similar. This is part of the magic that turns what would otherwise be static files into something that can generate an entire web site filled with content that can then be deployed as HTML, CSS and JavaScript.

M is for More

And this is where the M in JAMStack goes beyond just the Markdown, HTML, YAML and Liquid you may use. Almost any site includes JavaScript, APIs and Markup, but not all these sites are built with JAMStack. The M includes the build process to put these together - meaning the M includes your static site generator. If this is a little bit hidden in the name, that's not entirely unintended. To understand why, you need to look a little bit at the history of this approach to web development.

JAMStack was a term essentially created by Netlify in conjunction with some other companies beginning to work on the tooling for this approach back around 2016. Having written books and articles and presented on the topic extensively, I was approached about it back then and, to be honest, I didn't love the name at the time, but I understood the reasoning behind it and, truthfully, didn't have any better suggestions.

The problem was that up until then we'd been simply calling them static sites and they were built with static site generators. This didn't reflect the reality, which was that these sites had become increasingly dynamic. Today's JAMStack sites are often indistinguishable from any other dynamic web application incorporating things like dynamic content, authentication, and much more. Calling them static sites would be both unfair and misleading. So JAMStack it is - but let's emphasize the M!