The JAMstack in 2019: Why (and How) to Get Started

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.

I think it’s fair to say that we’ve played our part in this movement—crafting nearly fifty JAMstack-relatedblog posts & Github repositories with actionable, live demos.

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.

I’ll cover:

1. How to get started with it
2. How to sell the JAMstack to clients
3. What are the best resources to stay up-to-date

Ready to JAM?

1. What is the JAMstack?

1.1 Definitions

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:

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

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

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 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 JAMstack_conf (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:

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 yourJavaScript skills. Then learning as much as you canabout 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.

In 2019, look no further than the Holy Trinity of JavaScript frameworks 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 projects written on top of them.

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

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 useHugo to generate the site, deploy it on Netlify, and use Netlify forms/ Staticman for comments .

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

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, 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:

• The New Dynamic
• JAMstack radio
• Netlify’s blog
• Alligator.io
• JAMstack.org
• StaticGen —a full list of available SSGs
• HeadlessCMS —a full list of available headless CMSs

… Andour 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 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.