Jamstack is small, but growing. The Web Almanac by HTTP Archive reveals that the number of websites built using static site generators (SSG) – a category in which Jamstack sits – almost doubled in 2021. Why such rapid expansion?
Done right, Jamstack can offer a combination of security, scalability, and portability. The architecture also has the potential for solid performance and is simple to maintain.
That said, getting started with Jamstack can be a challenge. We love it, but you should know the potential difficulties so you can plan around them – and hopefully avoid them entirely.
We’ve used Jamstack to build complex, multilingual, localised applications with nested categories and tags. On top of that, we’ve added plenty of dynamic content. Don’t worry if you don’t understand that just yet. But if you do, great!
The process has not been painless and building our expertise in the architecture took serious work – and investment.
If you want a balanced picture of what Jamstack is all about, read on.
Jamstack wasn’t invented, exactly. It gradually developed as a trend that Billman then labelled.
The term Jamstack was first coined by Mathias Biilmann – the CEO of Netlify – in 2015. It was originally styled JAMStack. But that was annoying, so now we spell it ‘Jamstack’.
Jamstack wasn’t invented, exactly. It gradually developed as a trend that Billman then labelled. That’s not to say that Netlify didn’t play a part in the emergence of Jamstack – they did.
The architecture that became known as Jamstack evolved as a practice among developers as a way to offer interesting, dynamic content quickly. It’s no coincidence that the CEO of Netlify was the one to give Jamstack its name. The company offers a web development platform that focuses on speed – both in website performance and development time.
As such, they are among the most high-profile and consistent advocates for Jamstack.
Jamstack stands for JavaScript, API, and Markup.
The name came about because any website built with Jamstack originally made use of these three pillars. And in case you’re wondering – yes, that is an oversimplification. But it’s largely true. If that’s a level of detail you’re comfortable with, you’re reading the right article.
If you need a refresher, we’ll define JavaScript, API, and Markup for you now. If not, feel free to skip ahead.
JavaScript (or, JS) is a programming language used to handle a website’s dynamic content – which is any content that changes based on user behaviour or other data without the need to refresh the page.
For example, on real estate websites you can often find a map that shows you where a home is located. You can zoom out to get a better idea of where it sits within a wider area or zoom in to see the home’s relationship to local streets. Odds are the site is using Google Maps to achieve this, which runs on JavaScript.
You never have to reload the page and the content in the map updates automatically – or, ‘dynamically’ – as you scroll around and zoom in and out.
If you just want text or images to sit on a page, you don’t need JavaScript. But on the modern web, that’s rare. Most sites today capable of satisfying modern user experience (UX) expectations involve some kind of dynamic content. That’s why JavaScript is an important part of Jamstack.
API stands for Application Programming Interface. APIs are how different pieces of software talk to each other – they’re the messengers of modern programming.
This is useful for most web development because it means developers don’t need to spend time and money reinventing the wheel every time they want something round that rolls.
But APIs are especially useful in an architecture like Jamstack where websites are built from a greater variety of separate parts.
The result is often a ‘custom stack’ made of different technologies. These are connected via APIs that web developers use to achieve their specific goals without being locked into any particular solutions.
In our earlier real estate website example, we talked about how the developers used a map built with JavaScript to help users understand the location of real-world properties.
Those developers didn’t need to build a maps platform themselves because they could connect their site to an existing one – the Google Maps Platform – with an API.
Markup is used to label and structure different parts of a website’s code so people and machines – like search engines – can use them properly. It’s written in markup languages like HTML and XML.
Imagine you write a school report about a book. At the top you put the title. To help the reader understand it’s the title you put it at the top of the page, leave a gap beneath it, make the writing slightly bigger, and underline it. Together, all this information signals to the reader that they’re looking at the title.
Markup is how we do that when coding websites. But instead of underlining the title and so on, we use tags. Tags are standard words that identify the piece of code they sit next to.
In HTML, examples of metadata include:
In Jamstack, the markup is used to help define the static aspects of a webpage like text and images.
Today, ‘Jamstack’ is used more loosely. A site built on Jamstack does not strictly need to include JavaScript, APIs, and markup. Any website with a decoupled front end built on a static site generator (SSG) with pre-rendering, and progressively enhanced with JavaScript can be described as having been built with Jamstack.
Decoupling refers to the fact that in Jamstack, the front end and back end are not integrated. Instead, the front end can be added to, adapted, or entirely replaced without having any effect on the back end.
A static site generator (SSG) automates the process of creating HTML pages by putting content into pre-made templates so it can be displayed properly. This way, developers don’t need to write every page from scratch.
If you think this is similar to a CMS (content management system), it is. However, there are important differences.
For example, a CMS offers a way for even non-developers to create great-looking static pages through an approachable GUI (graphical user interface) while an SSG can deliver slightly faster page loading times as page generation has already happened by the time the browser requests any information to display. With a CMS, it’s created at that point.
Which is better? We won’t win any prizes for originality here, but it depends what you want to achieve. Want to know which is better in your case? Ask us.
Prerendering is when you load each part of a webpage in a bot-friendly version before a search engine like Google asks to check it.
Since the web crawlers search engines use to judge your site are looking for speed – among other things – the lack of waiting around for the page to load makes them happy. This can help you with SEO.
Instead of seeing all the fancy dynamic JavaScript content, bots will only see static versions of your pages. They find the static versions easier to understand.
You might think after our section on SSGs that prerendering is about loading everything in advance for bots and humans alike, so that everything is faster for everyone.
But no. It’s for bots.
Prerendering is helpful for Jamstack sites because they tend to be enhanced with dynamic content using JavaScript. The prerendering helps prevent these sites from underperforming in SEO.
Progressive enhancement is a technique web developers use to offer different versions of a webpage to a visitor based upon their browser (or possibly their Internet connection quality or speed).
If you have a browser with limited capabilities or a terrible connection, a website built with progressive enhancement could show you a basic version of itself. It wouldn’t have all the fun dynamic content necessarily, but you’d still be able to make sense of pages with versions made readable for you.
The better your browser/Internet connection, the more features you might be able to experience. If you use progressive enhancement, all browsers should be able to display a comprehensible version of your website.
There are many potential benefits to using Jamstack. Possible upsides to Jamstack include:
Better performance. For example, you might serve your website to the client over a CDN (content delivery network). This can reduce load times much as visiting your local store can be quicker than waiting for a product to be delivered from a fulfilment centre.
Higher security. There are a couple of reasons Jamstack can be more secure. But a big one is serving pages up pre-generated. With read-only, there’s less that can be attacked.
More portable. A pre-generated site can be hosted in more places – including really simple and affordable static site hosting services. You won’t be locked into your current hosting arrangement.
Improved developer experience. This really depends on the developer, but the modularity of Jamstack potentially means breaking development responsibilities up into manageable chunks with fewer repercussions due to dependencies. Got a JavaScript developer? Have them work on JavaScript. No need for them to worry about anything else, especially on the back end.
You’ve probably noticed that most ‘learn about Jamstack’ pages only tell you about the benefits. But we think you should know about the challenges, too. Our advice as developers with real-life Jamstack experience is this; don’t ignore the challenges.
For your own safety, read on.
You may be familiar with the Sirens, those mythical seducers who lured sailors to their deaths with their beautiful song. There’s a non-zero chance those songs were titled ‘Benefits of Jamstack’ and the Sirens worked at Netlify.
We’re not saying Jamstack is trying to kill you. But with Jamstack, things can seem really easy at first before a bunch of difficulties hit you all at once. By reading about these challenges now, you can save yourself some serious hassle and maximise the upside of Jamstack’s sweet embrace.
Okay, they’re both sirens. But the one on the left is the kind we’re talking about.
Potential challenges of working with Jamstack include:
Of course, there are ways you can mitigate these challenges:
Educate anyone who’ll be working with your website on how to use the features they need to do their jobs systematically. Schedule tutorials, make a knowledge-base available, and most of all, let them know who to talk to if they need a new feature or want to report a bug.
Learn from our experience. Igor Łuczko, Chief Technology Office (CTO) at Develocraft, wants to give you this message:
“We've worked with complex, multilingual, localised applications with nested categories and tags. And a lot of dynamic content and routes. It was not easy. It was challenging to explain everything to the Product Owner. It was challenging to explain to Quality Assurance. Really detailed education and onboarding was needed.
On top of that, we had difficulties finding developers who understood the spirit of Jamstack at first. Developers new to Jamstack initially felt confused. They needed more onboarding than we could offer at first.
You may think the simple solution is to just hire a developer who already knows Jamstack inside and out. But that’s still tough – they are currently rare.”
What now?
Fortunately, we’ve already been through the pain of getting to know Jamstack. Develocraft worked on complex projects across multiple languages in a range of countries for clients with outsized requirements.
If you want to build a site with Jamstack, make life easy for yourself. Talk to us first.
