When we first wrote this post, the JAMstack ecosystem was still in its infancy.
That was +/- 4 years ago.
I remember talking with the Netlify founders back then. They had just come up with the term “JAMstack” to work around the negative connotation of “static web” and were asking if we would help to promote it.
“Yeah, sure” answered a very half-convinced me.
Boy, are we grateful today to have witnessed firsthand the rise of this now vibrant community.
We plan to keep up providing valuable resources to new & seasoned JAMstack developers alike in 2019. It starts today with this much-needed update of our introduction post.
Ready to JAM?
1. What is the JAMstack?
Let’s quickly get the basic definitions out of the way. The JAMstack isn’t a specific set of tools, but a new, modern way of building websites & apps. Where does “J-A-M” come from, you may ask? From these three concepts at the core of this paradigm:
APIs: All server-side functions or databases actions are abstracted into reusable APIs, accessed over HTTPS with JS. Be it SaaS, third-party services or custom-built.
Markup: Templated markup should be prebuilt at build time, usually using a site generator for content sites, or a build tool for web apps.
Great. But what does it all mean in practice?
For a long time, using a CMS was the norm: it organized development efforts and gave clients the autonomy to manage their site.
But that was 4+ years ago.
Countless developers have since felt the pains of working with a CMS.
We became aware that traditional CMSs (WordPress, Drupal) were just trying to do… too much. We realized how cumbersome they were. How opinionated. These user-friendly admins started feeling less friendly.
Thanks to modern browsers, static site generators, CDNs, and APIs, we’re now seeing web developers transition from dynamic server-side applications to modular, client-side stacks.
For those new to the concept, here are the best practices defining a JAMstack project:
- Entire site/app on a CDN
- Atomic deploys
- Instant cache invalidation
- Everything lives in Git
- Automated builds
But it didn’t come to life with just the snap of a finger. Like I said at the beginning, it’s been a few years in the making.
Let’s take a quick journey back in time with a year-by-year view of the rise of the JAMstack. It should clarify where it’s at right now and where it’s going.
→ 2015: Static sites are slowly making a comeback from the ruins of the web’s early years. The first CMS-deniers are making them “cool” again.
→ 2016: As you would expect, backlash occurs. Static sites aren’t cool at all—they lack too many features to build anything other than blogs. In the meantime though, a small group of developers is coining the “JAMstack” and slowly promoting its principles in modern dev circles.
→ 2017: The year JAMstack really comes to life, for a somewhat niche community. Static sites aren't “static” anymore. This modern web revolution gives you all the features you need to build “hyper-dynamic” sites & apps. Sequoia Capital, Mailchimp & Red Bull are a few of the first big enterprises to build JAMstack projects.
→ 2018: Here’s a phrase I would bet you’ve heard or read last year: “Just discovered the JAMstack and, oh my God, it's amazing!” Yup, it has made a mainstream breakthrough with more & more people are talking about it. Substantial funding was announced for tools like Gatsby, Netlify, Contentful, etc. It will also be remembered as the year of the first JAMstackconf (which we’ll make sure not to miss next time).
→ 2019: Hard to tell what the future holds, but it’ll no doubt be exciting. 2019 enters as the year of maturity & accessibility. Bud Parr brought excellent insights in his new year’s address:
We can now claim with confidence that there is a serious revolution happening in the web development universe. The traditional approach that has ruled for more than a decade isn’t the only player in the game anymore.
And it’s all for the best.
1.3 Workflows comparison (JAMstack vs. traditional)
Here's a quick primer to understanding key differences between the two approaches:
This graphic is a very stripped-down view of what’s actually going on under the hood. Here’s what it looks like when you zoom in:
→ Building and hosting are coupled.
→ A user requests a page. The file gets processed and served following a (long) series of interaction between a database, backend code, server, browser, and layers of caching.
→ Core updates are pushed to production servers, often through FTP. Database must be maintained or updated.
→ Content updates are pushed through traditional CMS, like WordPress or Drupal.
→ Building and hosting are decoupled.
→ A user requests a page. The file is already compiled and gets directly served to the browser from a CDN.
→ Core updates are pushed through Git; the site gets re-built entirely via modern build tools like static site generators.
→ Content updates are pushed through Git or a static site CMS.
1.4 Benefits for developers
We often break down JAMstack benefits in four main categories: better performance, higher security, cheaper scaling & better developer experience.
- The delegation of server-side & database operations removes lots of points of failures & security exploits.
- The static content served via CDN makes for extra speedy user experiences.
- The lesser complexity of development reduces costs.
- The reduction of bloat & maintenance + refreshing flexibility in workflows diminishes depression and alcoholism among developers.
Jokes aside, there’s plenty of value in the JAMstack approach, for developers and clients alike. I’ll emphasize the client part later on. First, developers need to know how to get started.
2. Getting started with the JAMstack
If you’re new to this whole idea of the JAMstack, you might be a little overwhelmed at this point. Knowing where to start is sometimes the hardest part.
Once you've got this covered, well, the sky’s the limit as they say—as long as you can find the tools to match your ambitions.
2.1 New projects
Starting from scratch is the best way to build a “pure” JAMstack. This way you can really choose all the necessary pieces to create what you want. As I explained earlier, building and hosting are decoupled. The first thing you’ll want to decide is what to use to build your site/app.
The modern frontend ecosystem may make your life hard here. Not because of a lack of relevant tools. Actually, it’s just the opposite! There are hundreds of possibilities, even if some clearly stand out.
JS is everywhere nowadays and nowhere is it more noticeable than in the evolution of these frameworks in the last few years. They’ve transcended the world of browsers to become the go-to for single-page applications (SPA), progressive web apps (PWA) and mobile apps everywhere.
Static site generators
Simply put, an SSG takes your site content, applies it to templates, and generates a structure of purely static HTML files ready to be delivered to viewers.
These popular JS frameworks I was just mentioning gave birth to some of the most powerful static site generators out there—Gatsby & Next.js for React, Nuxt & Gridsome for Vue. These are the ones that are currently bringing SSGs to whole new territories.
There are many others obviously, and they all have their appropriate use cases. We’ve made this resource to help developers find the right one for their needs.
What we’ll see in the next few months is probably less of them being created and the top players getting more mature. This will eventually lead to greater adoption.
Headless CMS for backend functionalities
Content Management Systems are really great for a few things: manage user permissions, editor roles and, obviously, content. So why not use them only for these tasks? That’s exactly what headless CMSs do—finally decoupling the backend administrative tasks from frontend views.
Most headless CMSs will fit with whatever frontend tech you’re using, while others are built to work primarily with specific tools. However, just like SSGs, there are enough of them to find the right one for you, no doubt.
Here’s something that should guide you through this quest.
So here’s a few use case examples of what your new stack could look like:
→ If you’re building an enterprise, highly dynamic app with SEO needs, why not use Next/Nuxt.js for statically rendered apps in the front, with Contentful as a CMS pushing your content to various platforms (PWA, desktop, web-app, etc.).
→ If you’re building an online shop for a client, why not prioritize performance with statically generated files (with, say, Jekyll!), add a lean content management system with, say, DatoCMS or Forestry, and plug in a simple yet customizable e-commerce solution like Snipcart (oops, shameless plug ¯(ツ)_/¯).
This whole process provides great flexibility and a renewed sense of fun for seasoned developers. Got to admit though, it’s quite hard to sell to newbies. Ease of adoption is something the JAMstack community has been striving to achieve for a long time now. However, I mentioned 2019 as the year of accessibility earlier, remember? I’m not talking through my hat here.
The arrival of tools such as Stackbit is foreshadowing this new step for JAMstack. What it will do is provide an interface for assembling a frontend stack, without complicated integrations. It’s still in beta, but it’s sure worth a look.
2.2 Migrating or refactoring existing projects
Frontend refactoring has never been simpler and more of a progressive process thanks to modern frontend frameworks. We’ve gone through it, iteratively migrating our old Backbone architecture to Vue.js. And we loved every part of this operation.
It's also true for the backend. I know that a lot of developers who used to work with WordPress and other monolithic CMSs are starting to eye the JAMstack with curiosity. Well, it’s getting easier to migrate traditionally built projects to more modern infrastructure.
SSGs like Jekyll offers an easy way to migrate CMS data thanks to importers. The same can be said about headless CMSs such as Contentful and DatoCMS—they ease the move from traditional systems to headless ones.
But what if you could actually make it even easier:
Use a good ol' traditional CMS as a backend UI, strap a JSON/REST API on top of it, and use your favorite frontend tools to render static HTML to browsers. This way, you can easily reuse data from an ongoing WordPress project, for example, and attach it to a whole new JAMstack.
Both WordPress & Drupal now allow you to do that headless setup. It looks like even the big players are taking modern frontend development very seriously. But trust me… it’s only a question of time before more monolithic CMS follow suit.
Pantheon, the website management platform for devs, has lots of resources on decoupling traditional CMS. If you're interested, start here.
2.3 Added functionalities/third-party services/SaaS
JAMstack sites being built today are more hyper-dynamic than static. The current API economy and explosion in SaaS offers an interesting à la carte approach. In other words, you can cherry pick the dedicated external services you need and adopt a truly modular development stack.
Whatever dynamic information you need to handle, there's probably something just for that:
- Tools like Webtask and Serverless can handle multitudes of backend functions for you.
- Tools like Snipcart, Foxy.io, Moltin and Shopify’s Buy Button can handle e-commerce.
- Tools like FormKeep, Typeform, Formspree, and even Netlify—on top of building, deploying, and hosting your project—can handle form submissions.
- Tools like Algolia, Google Custom Search, Fuse.js, Lunr.js and List.js can handle search functionality.
- Tools like Disqus and Staticman can handle user-generated content like comments & reviews.
3. Making clients feel the JAM
Developers aren’t alone in this new paradigm: clients are still at the center of most projects.
Of course, you’ll get eager head nods from developers when you mention how the JAMstack erases the need for complex dynamic caching. Clients though? That’s not how you’ll get them excited.
Because it’s just not their lingo.
So how can you make clients understand the benefits of switching to a JAMstack setup?
3.1 Turning technical features into business benefits
The short answer is to speak your client’s lingo. To vulgarize and show. I for one like to break down technical features and turn them into tangible business benefits.
Let’s take the removal of database queries, and the CDN-based content serving for instance. We can boil this down to performance. How can that have meaning for a client?
Well first, you could pop up a site speed test app like Pingdom or PageSpeed Insights and bring up two very similar sites (or the same one)—one static, one dynamic. You'd make sure the client sees the difference in results. You can then explain to the client how crucial page load time has become for on-site engagement and SEO. Simple association follows:
Now for the withdrawal of server-side parts, which epitomizes the reliability argument. You could explain that a dynamic site is like a six-story house of cards, more vulnerable to collapse because it has more parts, more complexity to its structure. A static site, on the other hand? Make it a 1 story house of cards.
Super easy to build and maintain. :)
And last but not least, you could translate reduced operational and development costs into hard savings:
“By ditching the big web server, the databases, the plugins, and the constant maintenance, we’ll save you X thousands of dollars a year.”
Hard to argue with that.
3.2 Refuting common objections
The JAMstack isn’t bulletproof yet. While discussing a switch to it, more tech-savvy clients or developers may bring up some (more or less) legitimate concerns. Here are the two objections we used to see frequently in online threads that could still come up in conversation:
1) A JAMstack set up is nice, but I need to handle dynamic features on my site.
I’ll repeat it one last time: the JAMstack sites built today aren’t static anymore. They’re hyper-dynamic. So regarding the presumed lack of server-side features, you should refer to the section about added functionalities & third-party APIs.
2) Static CMS are cool and all, but I also need to manage user permissions & editor roles.
Remember the parts about headless & decoupled traditional CMS? Well, here’s your answer to these concerns.
I know this isn't as sexy as a full suite of shiny new tools. And yes, it defeats parts of the purpose to adopt a full JAMstack. But it might just do the trick for your administrative needs! It could also significantly alleviate migration costs if all the content already exists in a traditional CMS.
4. Curated list of resources
If you want to keep up with the quickly evolving JAMstack ecosystem, or even contribute, here are a few resources you need to keep an eye on:
Over the years we also submitted a few of our own articles to the awesome-jamstack Github repo which is also an excellent community hub. Oh, lastly, you should follow #jamstack on Twitter!
Contribute to the JAMstack!
There are many ways you can yourself contribute to this web revolution:
- Contribute to open source repos you love or want to learn. There are dozens of SSGs, headless CMSs, and third-party services waiting for developers ready to lend a hand.
- Build a personal or side project with the JAMstack.
- Write an article or craft a video showing how you used the JAMstack for XYZ project. Platforms like dev.to or DailyJS let devs share helpful content.
- Support industry players you love by sharing their content or using their products.
- Try to sell the JAMstack for your next client project!
At Snipcart, we are always open to relevant guest posting from devs with killer content to share! Let us know if it’s your case.
We have some content coming up soon dealing with the question of “How to contribute to the JAMstack?” so stay tuned for that!
Feel free to start the conversation right here in the comments. Do you think the JAMstack has now come to maturity? If so, what do you plan on achieving with it? If not, what do you think is still missing in its ecosystem?
We sure hope the community goes on growing in 2019 and that the power of the JAMstack overcomes the last naysayers!
*Liked this post? Take a sec to share it on Twitter.