When we first wrote this post, the JAMstack ecosystem was still in its infancy.

That was +/- 5 years ago.

Back then, the Netlify founders came to us with a proposition. 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, greener Snipcart team.

Boy, are we grateful today to have witnessed firsthand the rise of this now vibrant community. It’s fair to say that we’ve played our part in this movement—crafting nearly fifty JAMstack-related blog posts & Github repositories with actionable, live demos.

The difference today is that this kind of content pops up everywhere! And don’t get me wrong, we’re all for it. It means the community is in good shape and growing stronger every year.

We plan to keep up providing valuable resources to new & seasoned JAMstack developers alike in 2020. It starts today with this update to our introduction post and what we think the year ahead has in store for devs.

I’ll cover:

Ready to JAM?

1. What is the JAMstack?

1.1 Definitions

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 core concepts:

JavaScript: Any dynamic programming during the request/response cycle is handled by JavaScript, running entirely on the client.

APIs: All server-side functions or database 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 coupled CMS was the norm: it organized development efforts and gave clients the autonomy to manage their site.

But that was 5+ years ago.

Countless developers have since felt the pains of working with 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.

JAMstack is a significant shift in focus from the now abstractable backend to the now powerful frontend.

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.

1.2 Timeline

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 we start to hear a lot: “Just discovered the JAMstack and, oh my God, it's amazing!” Yup, the paradigm makes a mainstream breakthrough with more & more people talking about it. Substantial funding is announced for tools like Gatsby, Netlify, Contentful, etc. The first JAMstack_conf takes place.

→ 2019: The year of maturity & accessibility. The JAMstack isn’t a niche community anymore. Most frontend developers hear about it and many start looking into it. With the likes of Stackbit, the JAMstack opens its doors to less technical users. The rise of serverless functions is also huge for bringing more backend functionalities to frontend-centric projects.

→ 2020: With a new decade on the horizon, there’s nothing indicating a decline in the JAMstack’s adoption. If services and APIs in the ecosystem continue to prove viable and profitable, we’ll see more important players embracing the idea, increasing adoption even more. The New Dynamic brought legit concerns about having too much options in the ecosystem in its first newsletter of the year. Food for thought, no doubt. Otherwise, I’d say the future looks bright for JAMstackers! More insights for 2020 coming in the last section of this post.

We can 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 Workflow comparison (JAMstack vs. traditional)

Here's a quick primer to understand 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:

Traditional workflow

→ 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.

JAMstack workflow

→ 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.

How so?

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.

First, remember that we’re talking about frontend-centric development here. If you’re new to web development in general, you’ll want to make sure to sharpen your JavaScript skills. Then learning as much as you can about APIs will allow you to push your projects to the next level.

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.

JavaScript frontend frameworks

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. The Holy Trinity of JavaScript frameworks is still where you should look at for getting started: React, Vue & Angular.

Just like I would recommend learning JavaScript’s basics before frameworks, I would also recommend learning these frameworks before jumping into building tools (like SSGs) written on top of them.

Oh, and in 2020, maybe also keep an eye on Svelte? This relatively new framework follows in the footsteps of React & Vue, while creating its own path looking forward. Svelte acts as a compiler. It ditches the virtual DOM and compiles components into JavaScript, resulting in much lighter weight and boosting performances.

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’re seeing right now is less of them being created and the top players getting more mature. Gatsby, for instance, has grown considerably in the last few months and is still going strong. Is 2020 the year where we’ll see incremental builds being supported? We sure hope so.

Good news for Angular developers: the first static site generator powered by Angular is finally here! Scully will certainly be a tool to monitor in the upcoming months. It means that all the major frontend frameworks now have their JAMstack tooling, leaving even more freedom for developers to work with the tools they love.

Another one that is getting a LOT of love by the community, from what have been reading, is the JS-powered 11ty. You can read more about this SSG here.

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. Newer CMSs even allow for built-in static site generation. 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.

Deployment

Once you’ve built your site/app, it needs to live somewhere. Most developers turn to GitHub pages, Netlify or Zeit to host their code.

So here’s a few use case examples of what your new stack could look like:

→ If you’re only creating a small blog for yourself, why not use Hugo to generate the site, deploy it on Netlify, and use Netlify forms/Staticman for comments. For content management and editing purposes, plugging a headless CMS (e.g. Ghost as a headless CMS) will make the life of less technical users easier. For blogs, there's definitely no shortage of cool options!

→ 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, Eleventy!), 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 🤷‍♂️).

→ If you’re crafting documentation to support a new project, why not go the same way we did crafting auto-generated docs thanks to the excellent mix of Nuxt & Sanity. We truly fell in love with these tools and are looking forward to leveraging them again in the future (the next version of our marketing website, maybe?).

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.

The arrival of tools such as the Stackbit site builder opens up this new era for the JAMstack. What it does is provide an interface for assembling a frontend stack, without complicated integrations.

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.

Pantheon, the website management platform for devs, has lots of resources on decoupling traditional CMS. If you're interested, start here.

I’ve myself migrated a personal blog from Medium to a static site powered by Gatsby & Netlify CMS. I described that process in this post.

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:

Webtasks and Serverless can handle multitudes of backend functions for you.

Snipcart, Foxy.io, Moltin and Shopify’s Buy Button can handle e-commerce.

FormKeep, Typeform, Formspree, and even Netlify—on top of building, deploying, and hosting your project—can handle form submissions.

Algolia, Google Custom Search, Fuse.js, Lunr.js and List.js can handle search functionality.

Disqus and Staticman can handle user-generated content like comments & reviews.

Cloudinary can manage, optimize and deliver image and video content.

Auth0 can handle authentication and authorization for web and mobile apps.

And the list goes on and on.

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, there was 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.

Plus, with the extensive offer in headless CMSs and serverless functions, there’s practically no backend functionalities that are off-limits anymore.

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 to keep an eye on:

… And our blog, obviously! Make sure not to miss anything by subscribing to our newsletter. 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 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 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!

Attend the JAMstack Conf 2020! It takes place in London on May 27-28th and in San Francisco on October 6-7th.

At Snipcart, we are always open to relevant guest posting from devs with killer content to share! Let us know if you’re interested.

5. Closing thoughts

Feel free to start the conversation right here in the comments. Where’s your head at when it comes to the JAMstack? Are you all in? Still having doubts? What are you looking for the most in the ecosystem in 2020? We’d love to read your opinion.

I’ll end this (long) post on a more “personal” note. As a team and a business, we’re still 100% behind the JAMstack and constantly in awe of the expansion it has been through in a short amount of time. Here are rapid-fire thoughts coming from the Snipcart team members:

Looking forward to new (or improvement of existing) tools to manage medium to large JAMstack projects—SaaS subscriptions management, top-level observability of a whole setup, etc.

With the increasing regard to building fast web experiences, a wider adoption of the PWA movement is to anticipate. We think it’s great news.

web experiences, a wider adoption of the PWA movement is to anticipate. We think it’s great news. I mentioned it earlier, but the release of incremental builds in static site development in 2020 would be game-changing. Looking at you Gatsby! 👀

Going more mainstream will mean a significant bump in marketers/SEOs adoption.

It should also lead to more awareness in the WP ecosystem. The likes of WP2Static, Strattic and Shifter are already leading the way.

We’re big Vue proponents at Snipcart, so we’ll hopefully see more Vue-powered JAMstack tooling like Gridsome coming to life.

And, finally, a stronger focus on bundling tools like Stackbit or Netlify can only help to open the JAMstack to a wider audience and boost accessibility.

Let’s hope 2020 meets our expectations! In the meantime, happy coding to you all. :)

Liked this post? Take a sec to share it on Twitter.