JAMstack for Clients: Benefits, Static Site CMS, & Limitations

Johnson Wang, Unsplash

Like ol’ Heraclitus once said: the only constant is change.

As web professionals, we know for a fact he was putting it mildly. Between our first coffee and our last email, dozens of new tools materialize. We live and breathe change.

Today, I want to discuss one of the changes we, as web professionals, are going through: the rise of the JAMstack & “static” sites. A change that’s affecting not only us, but clients too. First, a little (admittedly familiar) backstory.

Dynamic CMS: these bittersweet tools of ours

Before launching our own SaaS for developers, we were hard at work in a Québec City dev shop. We built apps, software and, yes, websites for clients.

So we experimented with different site-building tools out there. Like most shops, we ended up picking a go-to CMS and sticking with it. Back then, using a CMS was the norm: it organized development efforts, and gave clients autonomy to manage their site.

But that was 4+ years ago.

Like countless developers, we soon felt the pains of working with a CMS.

We became aware that traditional CMS were just trying to do… too much. We realized how cumbersome they were. How opinionated. And we kept receiving support requests from clients who “just couldn’t figure it out.” These user-friendly admins started feeling less friendlier.

Now don’t give me the typical WordPress usage statistics — it only got away with it because people got used to the dashboard. Doesn’t mean it’s any good.

Today, unsurprisingly, things have changed. CMS have increased in numbers and types, and interesting variants are making their way into our workflow, like flat-file CMS Kirby & Statamic for instance.

But more importantly, “static” sites have made a remarkable comeback.

Tell ‘em LL

“Static” sites & JAMstack on the rise

You may have heard of this new development paradigm aptly baptized the JAMstack (JavaScript, APIs & Markup). 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. 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

The above were taken from Netlify Co-Founder Mathias Biilmann’s SmashingConf presentation.

JAMstack & static sites vs traditional CMS workflows

Here’s a quick primer to understand key differences between the two approaches:

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.

Of course, the latter brings in lots of benefits:

• 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. Want to dig deeper? Start with this piece on static site generators.

Making CLIENTS feel the JAM

There are plenty of JAMstack and modern static web resources for developers. Sites like Smashing Magazine, SitePoint, Heavybit, Netlify’s blog, ours, The New Dynamic, and StaticGen are all filled with valuables tools, articles and tutorials.

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

And while always experimenting with new tools to do better work is important, educating your clients is also a quintessential part of your job.

We faced similar communication obstacles with our own startup: developers understood the underlying promise of a lightweight, frontend shopping cart platform. But explaining the benefits of using an HTML/JS shopping cart to a client who is already comfortable with WooCommerce & Shopify? That proved to be a challenge.

The same issue will apply here with clients who’ve been comfortable in their WordPress admin for years.

So how can you make clients understand the benefits of switching to a JAMstack set up?

Turning technical features into business benefits

The short answer is to talk the client 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 testmysite.io 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:

→ Static site = faster site = better user experience & Google rankings = more traffic, more $

Now for the withdrawal of server-side parts, which epitomizes the reliability argument. You could explain that a dynamic site is like a 6 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. :)

→ Static site = simpler site = more secure & reliable = less unpredicted expenses, peace of mind

And last but not least, you could translate reduced operational and development costs into hard savings:

“By ditching the the big web server, the databases, the plugins, and the constant maintenance, we’ll save you X thousands of dollars a year.”

Refuting common objections

While discussing a switch to the JAMstack, more tech-savvy clients or developers may bring up some legitimate concerns. Here are the two objections most frequently seen in online threads, along with relevant replies:

1) A JAMstack set up is nice, but I need to handle dynamic features on my site.

Truth is the JAMstack sites being built today are more hyper-dynamic than static. So regarding that presumed lack of server-side features: you can remind clients that 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 clients 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, Foxycart, Selz, Gumroad 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.

And the list goes on and on.

2) Static CMS are cool and all, but I also need to manage user permissions & editor roles.

As we’ll see in the next section, this is a recurring pain point with many modern “static” CMS. But the fact is some advanced headless CMS like Contentful, Prismic and Directus already let you manage lots of roles & permissions. Should they not fit your needs, there’s another interesting way around the issue:

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.

Both WordPress & Drupal will allow you to do that.

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

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 greatly alleviate migration costs if all the content already exists in a traditional CMS.

Leveraging social proof & success stories

Your clients still need convincing after all these technical and business arguments? Steal an old trick from the marketing playbook and make them look at everyone who’s doing it!

From Sequoia Capital, Mailchimp, New Relic to Red Bull, there are already lots of cool JAMstack projects to cite out there. In the spirit of conciseness, we’ll just share a few lists from which you can pick example sites to show off:

• Netlify’s Site of the Week section (full stack breakdowns)
• Contentful’s customers case studies
• Sites built with Middleman
• Sites built with Jekyll
• Sites built with Hugo
• Sites built with Gatsby

There are tons of ways we can get clients excited about the JAMstack. Still, convincing them is only the first part.

Because at the end of the day, static or not, clients will most likely need to manage their content. Update pages, publish articles, change images, add promotions, you name it.

Static site CMS: JAMstack tools for clients & limitations

And that’s where “static” CMS step into the arena.

Static CMS, herein illustrated by Bill “Save the Day” Murray in Space JAM.

There are lots of solutions to add a layer of content management on top of JAMstack sites. From Jekyll-specific apps to headless API-first CMS, these static tools come in all shapes and sizes.

Note: head this way for an in-depth primer on full-fledged headless CMS.

Here are the ones we tested, along with colleagues from our former dev shop:

• Contentful
• Prismic
• CloudCannon → [see our tuts]
• Forestry
• Siteleaf
• DatoCMS
• Bowtie
• Jekyll Admin
• Prose
• Netlify CMS
• Appernetic
• Drive CMS
• Meethyde
• Directus

As developers, we admire the work and thinking that went into building these modern tools. Thanks to them, managing content on JAMstack & static sites is now a mostly viable option for non-technical users. But as former agency members, we couldn’t help but get stuck on a few details. And I mean both client and tech-related details here.

In a way, the current state of most of these CMS for static sites is that they’re not equipped to be “full mission control” like traditional CMS. Why you ask? Here’s a list of hopefully constructive complaints we compiled:

• UIs are rarely customizable for specific client needs and sometimes lack polish.
• UIs aren’t always responsive, so limited mobile access for on-the-go management.
• Image uploading usually doesn’t use an “image cropper”, which leads to potential performance issues with media format, weight and size.
• Some CMS force you to use their own hosting, CDN, SSL, deploy. Others just limit developers when it comes to freely managing web perf.
• Some CMS are limited to specific static site generators, reducing the developer’s range of tech stack choices.
• The ability to assign roles, restrict access, and define types of users isn’t always available. Same thing goes for the famous “preview” function.
• Generally, site arborescence isn’t displayed in the admin.
• Multi-language and geolocalization are rarely supported.
• Dynamic features like forms, logins, or memberships are almost never supported out-of-the-box.
• And last but not least, prices are often high.

As we’ve seen earlier, there are ways around some of these issues, notably API-centric 3rd parties for dynamic parts & headless or traditional CMS as a “backend UI” for roles & permissions.

Of course, we’re aware these tools are still young. Time, usage and feedback will allow them to grow. And we’re also aware that the JAMstack benefits will, in many cases, outweigh these drawbacks for clients. And if the tradeoffs make sense, we’d urge agencies and developers to hook their customers up with such modern stacks.

The thing is: clients have been using traditional CMS for years now. Thus, they have built both financial and functional expectations towards these “tools to manage their website.” With the current state of static CMS, it can be hard to manage these expectations. Doing so might include a little education and a slight learning curve.

So, are JAMstack & static sites the best option for client projects?

Even in web tech time frame, the JAMstack in itself is still new. As developers, it’s becoming a no-brainer for us to consider the advantages of such sites & apps: reliability, simplicity, and speed are benefits too obvious to ignore. But the ecosystem of static CMS tools for non-technical users and clients still needs polishing, and maturity. And it’s okay: the traditional CMS admins we’re comparing them to were 15+ years in the making!

One thing is certain: the “non-technical users won’t be able to manage content” argument without a traditional CMS doesn’t stand anymore. But the question remains:

Is a JAMstack set up really what’s best for your client?

Well, you’re the judge here, so use your head! In a sense, clients are fundamentally agnostic to your tech choices, but sensitive to their end user needs. It’s your job to factor in:

• Overall prices of solutions used
• Total development and maintenance costs
• Client education and learning curve
• Client organizational & administrative needs
• Project technical requirements

If you’re hesitant about choosing the right tech stack for your clients, you might want to read this guide a good friend of ours put together.

We sincerely hope this gets the discussion going around the JAMstack. And we also hope this encourages developers to 1) try these tools for themselves and 2) find appropriate client projects to build with them!

BONUS: Curated JAMstack tutorials

• Setting Up Your JAMstack from Scratch — [environment set up]
• Sample eCommerce Site with Snipcart — [Prismic.io, Node.js]
• New to JAMstack? How to make a site from A to Z — [Hugo, Netlify]
• Dynamic Product Management in a Static E-Commerce Workflow — [Middleman, Snipcart, Contentful]
• Exploring Netlify CMS, a React & Git-Based Content Management System
• Serverless JAM — A Serverless Framework Tutorial — [Serverless, AWS, Netlify]
• JAMstack e-commerce with Siteleaf & Snipcart — [Jekyll, Snipcart, Siteleaf]

I originally published this on the Snipcart Blog and shared it in our newsletter.