Should You Be Using the JAMstack for Your Projects?

Should You Be Using the JAMstack for Your Projects?

Jamstack is an architecture designed to make the web faster, more secure, and easier to scale. The key to understanding JAMstack is knowing the difference between static and dynamic in the web world.

What’s the JAMstack all about?

The JAMstack has been getting a lot of buzz since it came into being, and there has been a lot of talk in web development communities as to whether or not you should move from WordPress to JAMstack. I thought I should write an overview article about this so that you can see if it is the right choice for your project.

The key to understanding JAMstack is knowing the difference between static and dynamic in the web world.

Simply put, static means that you have pre-built or pre-computed something and pre-compiled it on a static hosting system. Dynamic is where you are actually building something on the fly, computing it in response to every single request. When you think about it intuitively, it is going to be a lot faster and a lot cheaper to respond with something you already have, as opposed to computing something on the fly in response to every single request.

Some of the things that have always been static include JavaScript, audio and video files, and CSS. Yes, JavaScript is dynamic. True. It is dynamic on the page and its behaviour, but the code itself is always going to be consistent from release to release of a piece of software. It is very important to understand that any time you are computing something in response to a request, you are going to have a performance or scalability problem. If you can pre-compute the response — even if it is for a short period of time — you are going to be better off.

An old-school web server has three primary jobs: Serve HTML, static assets, and API endpoints. Nowadays, all your static assets are going to be on something like Amazon’s S3. When it comes to APIs, we have already moved those onto other servers or a set of servers if you are doing the micro-services thing.

This leaves the web server doing just one job, and that is serving HTML pages. If that is so, can we make those pages static? For that, we need to understand how a web server renders an HTML page.

Say a visitor goes to Medium’s home page. The request goes to the server, which connects to the API, asks for the data on the page, formats the HTML response, and then sends it back to the visitor fully rendered.

Image for post

Over the past ten years, web dev has been moving more towards client-side rendering. In that model, the user makes the same request to the server, but the server responds with essentially a blank page and a reference to a JavaScript application, which then makes the request to the API. That API responds with data. The client code (JavaScript ) then formats that data and renders it into the experience on the client side.

Image for post

There is yet another new way of doing the same thing. During build time, in response to data or code changes, a server goes and gets a list of all the data from the database and then uses a set of templates to format a site that has all of that in it. All of those pages are completely pre-rendered and go up on something like Amazon’s S3. When the visitor goes to that page, they immediately get back a page that is completely rendered.

Diagram of pre-rendered approach

The beauty of this is that you only have to render that data once into HTML. In the other models (client-side and server-side rendering), you render that HTML every single time, regardless of where it is being done. A key element is that every customer is going to get the same HTML page for a given URL. In two of these models (client-side rendering and static site generation), we can get rid of that web server and save ourselves a whole lot of time and money, which is usually everyone’s goal.

This is what JAMstack is all about.

JAM is an acronym. J stands for JavaScript, A stands for APIs, and M stands for markup. HTML is the hypertext markup language in the stack. In order of execution, it is actually markup, JavaScript, and then APIs. So ideally, it would be MJA, which wouldn’t really make a good acronym. Anyway, it is called a stack because that is the term given anytime you have a bunch of technologies working together. I think that is enough of an explanation for now. Why should you use the JAMstack?

  • It’s better for performance because anything you can serve off of S3 or any kind of static hosting site is always going to be faster than something that you can serve off a web server.
  • You do not need to monitor any servers anymore. It is always going to be available. If it was there yesterday, it is going to be there today, tomorrow, and in the future as long as you keep paying the bills.
  • It is much more secure. I mean, it is really hard to hack a server that does not exist.

jamstack api javascript programming developer

Bootstrap 5 Complete Course with Examples

Bootstrap 5 Tutorial - Bootstrap 5 Crash Course for Beginners

Nest.JS Tutorial for Beginners

Hello Vue 3: A First Look at Vue 3 and the Composition API

Building a simple Applications with Vue 3

Deno Crash Course: Explore Deno and Create a full REST API with Deno

How to Build a Real-time Chat App with Deno and WebSockets

Convert HTML to Markdown Online

HTML entity encoder decoder Online

A Simple Guide to API Development Tools

APIs can be as simple as 1 endpoint for use by 100s of users or as complex as the AWS APIs with 1000s of endpoints and 100s of thousands of users. Building them can mean spending a couple of hours using a low-code platform or months of work using a multitude of tools. Hosting them can be as simple as using one platform that does everything we need or as complex as setting up and managing ingress control, security, caching, failover, metrics, scaling.

Tracking a Developer’s Journey From Documentation Visit

Measuring website activity provides only half the story. See how to best track the developer's journey and what funnel stages makes sense for API-first products

How to Market to Developers with Paid Marketing

Selling to developers is hard. How to market to developers efficiently using paid advertising leveraging inbound marketing techniques.

54% of Developers Cite Lack of Documentation as the Top Obstacle to Consuming APIs

APIs are perceived as reliable—more than half of respondents stated that APIs do not break, stop working, or materially change specification often enough to matter.

5 Major Factors Impacting the Evolution of APIs

In today’s world of ever-increasing digital interconnectivity, APIs have emerged as essential tools for integrating data efficiently and cost-effectively. In this article we'll talk about the following five main factors behind the remarkable evolution of APIs in recent years