What is Jamstack?

The benefits were clear: you could now serve more customized content to the user.

The downside? It required more server resources to build, and thus the content would be delivered to the user slower than if it had been an old-school static HTML file.

Unfortunately, there was nothing to do about it at the time. To serve customized content, you had to let your server and database build it. That all changed with the invention and maturity of JavaScript. Today it might be hard to imagine the internet without JavaScript, but that was the case for the first few years before Brendan Eich wrote the first prototype Called "Mocha". It was later renamed "LiveScript", but that only lasted 3 months until JavaScript became the final name.

JavaScript was developed to allow browsers to dynamically alter a page after it was loaded in the browser. This fundamentally changed how developers could work with dynamic behavior in websites, and since all major browsers adopted JavaScript, it became a universal runtime layer. The browser was no longer a simple document viewer but could handle complex tasks that altered how content on a website would look and behave. 

This development added huge benefits to all websites. Not only could they now use JavaScript to add dynamic capabilities to their website after it loaded, but they could also move some of the workloads from the server-side to the client-side. This meant a better user experience for website visitors, and faster delivery as the browser would now help carry some of the load of building the page.

This last point is important when talking about Jamstack websites: shifting the workload from server-side to client-side. 

JavaScript

Jamstack websites are built to be flexible and not have one part of the architectural setup limit another. When you use a traditional content management system (often referred to as using a monolith system) you have everything coupled together. The database, content, and frontend templating are all handled in the same system, which means it's all dependent upon each other. While there's nothing inherently wrong with that (in fact it's often a great help), it can be limiting in terms of functionality and performance.

To avoid this lack of flexibility, a Jamstack site is split up and each part serves more specific and limited purposes.

JavaScript is in charge of displaying the content to the user and ensuring a great user experience. And since it is all decoupled from the content, it has complete freedom in how to do it. And although the "J" in Jamstack stands for JavaScript, it actually doesn't even have to be JavaScript. If you prefer to use something like Ruby, Python, or Go, you can also do that.

And that's the beauty of it all: you have the flexibility to choose which framework to use and how you want to use it. 

APIs

Application programming interfaces (APIs) are what is used to define what type of interactions are possible between multiple software services. Initially born in 2000, APIs have evolved a lot since then. As with a lot of other technologies in that age, APIs were developed to fit the workflows and processes of web development back then.

That meant APIs were only meant to be consumed by server-side applications, as that was the way it was done at the time. But with the development of new JavaScript standards, this all changed. Web APIs were developed and became available to any JavaScript client running in a browser.

This was a complete game-changer and is one of the big momentum swings for the JAMstack architecture. With web APIs, the server no longer needs to do all of that heavy lifting. Instead, it can all be moved to the client-side with JavaScript. And with APIs becoming more and more available for pretty much anything, there's a big movement towards using them as microservices. These microservices are essentially small pieces of code that serve specific functions, completely independent of other services. This creates an architecture of services that work independently but seamlessly integrate and connect to deliver a web of functionality.

The beauty of web APIs is the flexibility to use best-of-breed solutions and services instead of being forced to use something by your current system.

Markup

Content is king, and in Jamstack, it comes in the form of markup.

HyperText Markup Language (HTML) is at the core of the modern web and is understood by all browsers. The core functionality of HTML is to present a Document Object Model (DOM) that is ready to be parsed, presented, and processed by web browsers. But it is not limited to web browsers only. Different technologies like search engine crawlers, smart devices, and screen readers can also work with the DOM. 

While HTML has come a long way, its primary job is still to serve up content and its structure to the browser to display. This has not fundamentally changed with Jamstack sites. But the way it is being done and served has.

Instead of relying on the server to build all the content with every request by a client, it relies on cached content. This is done by using a build tool (like a static site generator or a frontend build tool) to pre-build the markup and deliver it to a Content Delivery Network (CDN). With this approach, the server will not have to work in real-time on new requests, but instead work only when new changes are made to any content or assets.

With the markup pre-built and ready to be consumed, it is up to JavaScript to call in the content it needs. If dynamic or customized content is required, APIs will handle it instead of having the server request it from a database. 

Using Jamstack vs. a traditional CMS for your website

The main difference between a Jamstack website and a website built with a traditional content management system is how tightly the content, code, and design are connected.

With a traditional CMS, you'll be handling everything in the same system. You'll have a backend interface where your developers will be handling all of the code and design templates. Your content will also be created, updated, and managed from a backend interface, and it will all be stored in databases on a server. Once a page on the website is visited, it will be assembled by the server and delivered to the visitor, and the page is shown.

With a Jamstack site, you're decoupling all of these parts and handling them separately. This decreases any dependency and gives you the freedom to choose your own tech stack. One key difference is how pages are generated for a website visitor. With a Jamstack site, you're almost entirely relying on the client-side instead of the server-side. Your pages will be stored in a cache - typically using a CDN - as HTML and JavaScript, which will be ready and waiting for the visitor to come by. Once a visitor visits your page, it'll all be ready for it to handle - without having to go back to the server and assemble it.

Can I use a Jamstack CMS?

As mentioned in the beginning, Jamstack is mostly an architecture focused on splitting up the code, infrastructure, and content, to have as much of the load as possible pushed to the client instead of the server.

To accomplish that, you can tailor your tech stack to fit your needs and preferences, including using a CMS for your Jamstack website or application.

An example is using a headless CMS, which allows you to do the same split between server-side and client-side. A headless CMS uses a decoupled architecture to push logic and load away from the server to the client - just like you want to do with the Jamstack architecture.

So if you're looking for a Jamstack CMS, you should look at some of the headless content management systems available on the market (Umbraco being one of them).

What are the pros and cons of using Jamstack?

Pros of using Jamstack

• It can be blazing fast. Since the Jamstack relies less on a server and the database, it'll often load very fast for the page visitor. By effectively caching all of your content on a CDN and focusing on a clean front-end code, you avoid many of the processes normally involved in loading a web page.
• The website is secure. The decoupling of the backend and frontend effectively means that any security flaws that might be exploited in the frontend code won't mean a security breach in your backend application. These are separated by an API and will mostly be read-only. At the same time, you're much less reliant on a database, which minimizes the potential issues.
• Scaling is easy and cheap. Since you're not relying on heavy server or database processing, you won't run into the same limitations as you can normally. You're only serving static assets and let the client handle most of the heavy lifting. With a powerful CDN, you'll need fewer resources to scale your website. This means that scaling is not only easier but will often be cheaper as it won't require you to upgrade servers.
• Great developer experience. You get all the flexibility in the world as a developer since you can choose your own tech stack. Developers can do their thing without worrying about the limitations of a certain platform or technology. And with the rise of microservices and reusable APIs, it's becoming a lot simpler to reuse functionality across multiple websites or applications.

Cons of using Jamstack

• Not content editor-friendly. Developers might love it, but that is not necessarily the case for content editors and marketers. Since you have to serve your content as Markup, your editors will need to be fairly technical to create and update content. This can often require teaching your editors new skills and will slow down content production as they lose editor features they're used to from a CMS. At the same time, they'll be responsible for proper media management, which can be tedious.
• Updates = coding. If you want to make any updates to your templates, you'll need to do it by coding. With the content being decoupled from your frontend there's no easy way for editors to customize the templates. This will often mean that developers will have to spend more time making the updates since they can't be easily changed in other ways. 
• Dynamic features require more heavy lifting. Jamstack sites are great as long as we're building pages with text and images. As soon as your site requires dynamic features, you'll potentially run into issues. Without having a database to process your requests, you will need to do more of the heavy lifting yourself with your own code or API calls. This doesn't mean it's not possible, but it requires more resources to achieve as you don't have these dynamic features as part of your architecture.
• Live and die by third-party systems. Since your website is heavily reliant on third-party systems and APIs, you're relying on them to be consistent. If a third-party system or API goes down, so does your website (or parts of it). This is no different from a normal website where the server goes down, but with a JAMstack site, it's very limited what you can do to fix the problem if it's an issue with a third-party provider. 

What is a static site generator?

The number one thing that static site generators have in common is that unlike conventional website builders they don’t depend on a web server. Instead of building each page on demand, a static site generator generates all the pages of the site when there are actually changes to the site. This means a visitor doesn't have to wait for the database to create a page before loading it. Instead, the page will be ready right when the visitor lands on the page and the client will be doing the heavy lifting. This makes caching much easier and the site faster by utilizing a content delivery network and client-side processing instead of relying on a server.