What is JAMstack?
The name itself was originally coined by Mathias Biilmann, co-founder at Netlify, who wanted to make it easier to refer to this new way of doing web architecture.
A brief history of developing websites
To understand why the JAMstack architecture is becoming popular today and not 10 years ago, it's worth taking a quick history lesson. In fact, let's take a look at how websites used to work and how it's evolved from there.
In the very early days of the internet, everything was more simple than we might think about today. The first websites that were built were all really just a folder with HTML files that could be requested by a browser. And that was pretty much it. The HTML would determine how the website looked and the content in it, while the browser's only job was to let the user view the page.
As the internet and the technologies surrounding it evolved, it allowed for more advanced websites and as a website owner, you got a lot more possibilities of what you could do. The first real change here was how content was being served. Static HTML files were no longer enough. Instead, it was necessary to serve customized content to the users of a website.
In order to serve customized content, the HTML of the website had to be built by the server at every request. This was a giant leap from serving simple HTML files. Now the user would request a page and instead of having it ready, the server had to consult a database and then build up the right content for this specific user.
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.
This last point is important when we're talking about JAMstack websites: shifting the workload from server-side to client-side.
Why use the JAMstack architecture?
The main reason to go with JAMstack instead of a traditional approach to website development is to go as server-less as possible. That means taking away as many tasks as possible and pushing them to the client instead to enable fewer server requests and thus better performance and faster load times.
The only way to do that is to think of the tech stack in a different way than previously. The classic way of talking about a tech stack is to mention operation systems and databases.
With JAMstack you instead focus on a different level of the tech stack: the level that is actually the real constraint on a project.
These constraints boil down to the 3 core parts:
- APIs to replace the database and fetch everything you need directly from the services required.
- Markup to serve the actual website content and HTML needed.
Let's have a look at the three individually.
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 get around this lack of flexibility, a JAMstack site is instead completely split up and each part serves more specific and limited purposes.
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.
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.
The beauty of web APIs is the flexibility you get to use best-of-breed solutions and services instead of being forced to use something by your current system.
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 of the content with every single request by a client, it is relying 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.
Using JAMstack vs. a traditional CMS for your website
The main difference between a JAMstack website and a website built with a content management system is how tightly the content, code, and design are connected.
With a 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.
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 a lot 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 that can occur.
- 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 run into. You're only serving static assets and lets the client handle most of the heavy lifting. With a powerful CDN, you'll be needing much 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. As a developer, you get all the flexibility in the world, 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 a tedious process.
- 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 on 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 goes down or an 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 yourself 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.
Is JAMstack the future?
Yes and no. For the right project, JAMstack is definitely a good solution and the decoupled architecture brings a lot of advantages to many websites.
The state of JAMstack right now is still on the technical side though, with both developers and editors needing a certain level of technical skills to be successful. So if your team does not possess the necessary skills to work efficiently with the JAMstack, then you might not see the results you want to.
It won't matter how fast your website is to a visitor if all they see is the same old content, that your editors are struggling to update.
If you want to negate the primary con of a JAMstack site - the editor experience - you should take a look at using a headless CMS. By doing so, you'll still be able to rely on a decoupled architecture with RESTful APIs serving the content, without compromising the editor experience.
Report: The state of Headless CMS 2020
Topics covered in the report:
- Why discussing headless is important
- What the main reasons are for choosing headless
- Whether demand is increasing - and why
- Which industries are using headless, and for which type of project
Can I use Umbraco for JAMstack sites?
Yes, you can use Umbraco to build a JAMstack website or application.
The Umbraco CMS is not a headless CMS out-of-the-box, but it's built with the flexibility and extendability to make it into a headless CMS if you want to. Everything in the Umbraco backoffice is connected with open APIs, so if you want to use a different front-end to serve your content, you can build it. This would require you to customize Umbraco, but it is definitely a great use of the open source version of Umbraco.
If you don't want to build it yourself, you can go with Umbraco Heartcore.
Umbraco Heartcore is the official headless CMS, hosted and managed by Umbraco HQ. It's based on the open source CMS and the editor experience that you know from the open source CMS, but packaged as a managed and hosted SaaS solution. This gives you a content management system that is focused on giving your content editors a great experience, without having to worry about learning Markdown or having to deal with managing media.
For developers, it's ready to use with open RESTful APIs and GraphQL that you can connect to the frontend of your choice. And with Cloudflare CDN included and a managed API, you don't have to worry about maintaining another codebase or API.
If you're interested to learn more about Umbraco Heartcore you can go take a look at the product features here.
Do you want to try it out for yourself? Then you can take a 14-day free trial.