To start, JAMstack is a software architecture and philosophy that adheres to the following components: Javascript, APIs and Markup. If this sounds familiar, it’s because it is! That React app that you compile down with Webpack and ultimately serve from S3? Yup, that’s a JAMstack app. That simple HTML file that has no JavaScript and literally doesn’t do anything dynamic? Yup, that’s also a JAMstack app.

That’s not to be confused with serverless: If you’re coming more from the cloud side of things (think AWS, GCP, Azure), you might be inclined to think of serverless and JAMstack as the same thing. Granted they have similarities in the philosophy of how resources are managed, such as hosting a site on S3. But a JAMstack app is not always going to be a serverless app. Consider an app hosted in static storage on the cloud provider of your choice. Yes, you might be serving the app in a serverless way, but you might be dealing with an API that utilizes WordPress or Rails, both of which are certainly not serverless. Combining these philosophies can go a long way, but they shouldn’t be confused as the same.

What makes up the JAMstack? Back to the JAMstack: it’s typically comprised of 3 components: Javascript, APIs, and Markup. Its history stems from growing the term “static site” into something more meaningful (and marketable). So while ultimately a static site is the end result, it’s blown up to include first class tooling for every step of the way. While there aren’t any specific set of tools that you need to use, or any tools at all beyond simple HTML, there are great examples of what can make up each part of the stack. Let’s dive in a little bit to each component.

• Javascript: The component that’s probably done the most work to popularize the JAMstack is Javascript. Our favorite browser language allows us to provide all of the dynamic and interactive bits that we might not have if we’re serving plain HTML without it. This is where a lot of times you’ll see UI frameworks like React, Vue, and newcomers like Svelte come into play. They make building apps simpler and more organized by providing component APIs and tooling that compile down to a simple HTML file (or a bunch of them). Those HTML files include a group of assets like images, CSS, and the actual JS that ultimately get served to a browser via your favorite CDN (content delivery network).
• APIs: Utilizing the strengths of APIs is core to how you make a JAMstack app dynamic. Whether it’s authentication or search, your application will use Javascript to make an HTTP request to another provider which will ultimately enhance the experience in one form or another. Gatsby coined the phrase “content mesh” that does a pretty good job at describing the possibilities here. You don’t necessarily have to reach out to only one host for an API, but you can reach out to as many as you need (but try not to go overboard). For instance, if you have a headless WordPress API where you host your blog posts, a Cloudinary account where you store your specialized media, and an Elasticsearch instance that provides your search functionality, they all work together to provide a single experience to the people using your site.
• Markup: This is the critical piece. Whether it’s your hand written HTML or the code that compiles down to the HTML, it’s the first part you’re serving to the client. This is kind of a de facto piece of any website, but how you serve it is the most important piece. To be considered a JAMstack app, the HTML needs to be served statically, which basically means not being dynamically rendered from a server. If you’re piecing a page together and serving it with PHP, it’s probably not a JAMstack app. If you upload and serve a single HTML file from storage that constructs an app with Javascript, it sounds like a JAMstack app. But that doesn’t mean we have to always build 100% of the app within the browser. Tools like Gatsby and other static site generators allow us to pull in some or all of our API sources at build time and render the pages out as HTML files. Think if you have a WordPress blog, we can pull in all of the posts and ultimately create a new HTML file for each post. That means we’re going to be able to serve a precompiled version of the page directly to the browser which usually equates to a quicker first paint and faster experience for your visitor.

One note about “hosting”: Using the term hosting here can be misleading if you’re new to the concept. Yeah, your site is technically getting hosted somewhere, but it’s not in the traditional sense. You don’t have a server that you’re maintaining where you upload your files to with an FTP client like Cyberduck. Instead, whether your doing it yourself with S3 or piping it into Netlify (which is actually multi-cloud), your HTML and static assets are getting served from object storage. On the tail end of that you typically have a CDN like Cloudflare which caches those files at locations all over the world making your pages load faster for the people visiting your site.

So what makes a JAMstack app so great? JAMstack apps inherently satisfy most if not all of the 5 pillars of the AWS Well-Architected Framework. These are core concepts that AWS considers to deliver fast, secure, high-performing, resilient, and efficient infrastructure.

Is my website considered to be on the JAMstack? We already talked about the 3 components (Javascript, APIs, Markup), but what we didn’t talk about is the fact that you don’t necessarily have to use all 3 of them in order to consider your site worthy of the JAM label. Really it all boils down to the Markup and how you serve it. Instead of your Rails app rendering your HTML for you, you might host a precompiled React app on S3 that reaches out to Rails via a set of APIs. But you don’t even need to have APIs. You don’t even need to have Javascript! As long as you’re serving an HTML file without it having to be compiled on a server at request time (aka pre-rendering it), you’ve got yourself a JAMstack site. – courtesy