Take 40% off The Jamstack Book by entering fcccamden into the discount code box at checkout at manning.com.

As Jamstack has gained popularity in recent years, one common criticism is that it’s nothing but a marketing term. The truth is, they’re right. As we’ll explore, Jamstack was a term invented to “rebrand” an architecture many developers were already using to build sites because the existing terminology had become misleading. Although calling it marketing may be a fair critique, Jamstack is still a way of building sites that has been gaining rapid adoption by web developers.

What is the Jamstack?

The Jamstack isn’t a simple thing to define. A Jamstack installer doesn’t exist and no predefined set of tools to install that comprise the Jamstack. IT doesn’t even have a specific language associated with developing Jamstack apps (yes, JavaScript plays a central role, but any number of languages may also be involved including Ruby, Go, Python or others). Ultimately, there are countless combinations of tools and languages that can be combined to create a site that could legitimately be called “Jamstack.”

What Jamstack is instead is more of an architectural pattern or methodology for creating sites. The key elements to this are:

• A Jamstack site is comprised of static assets – Jamstack sites are always deployed as static files. This means that they aren’t dynamically generated by an application server when the user requests a page, but instead the site files are generated at build time. For a Jamstack site, every user who requests a specific page in their browser gets the same static asset returned.
• A Jamstack site is built using a static site generator – The static assets in a Jamstack site are generated using a static site generator (SSG). At a basic level, an SSG is a tool that takes templates and combines them with content, typically stored as Markdown, YAML or JSON files, to dynamically generate the site’s HTML, CSS and JavaScript assets. This is similar to the process a dynamic web server like PHP might go through on each user request, but, instead, this process happens at build time, before the site is deployed.
• A Jamstack site uses APIs – What differentiates a Jamstack site from a simple static site is that, although it’s comprised of static assets, it can be extremely dynamic. The first key ingredient to creating this dynamic functionality are APIs. These APIs can be called by the browser client at runtime or even called by the static site generator at build time.
• A Jamstack site uses JavaScript for dynamic functionality – The second key ingredient to making a Jamstack site dynamic is its ability to call APIs and other services asynchronously on the client via JavaScript. JavaScript then enables the static assets to change dynamically via DOM manipulation. This enables things that otherwise seem impossible using static assets like a user login or a shopping cart.

Clearly there’s a lot of flexibility in this definition, which, in my opinion, is part of Jamstack’s appeal. It’s almost certainly a combination of Jamstack tools and services that meet both the needs of your project and your language, tooling and deployment preferences.

That flexibility has a cost though. Jamstack can be taught in many ways, and the multitude of options can make the learning curve for newcomers a bit steeper. Creating a site that uses a variety of APIs and services and dynamically updates content on the client using JavaScript has additional complexity.

Why choose Jamstack? The Jamstack evolved in part to address the problems of a dynamic web that many felt had become slow, costly and insecure.

The Benefits of Jamstack Architecture

Now that we understand that the Jamstack evolved from the early days of simple static site to a modern architecture for building complex sites, let’s answer the question: “Why should you choose Jamstack?” Here are some of the key benefits:

Performance

Three important aspects to the performance of Jamstack applications should be understood:

• Static assets load faster than dynamic ones – No processing needs to occur to turn dynamic templates into HTML, CSS and JavaScript and no database calls being made at runtime. All of these assets are “pre-rendered”, to use a term common in the Jamstack community which means that the rendering occurs at build time rather than runtime.
• Jamstack sites are served “from the edge” – Because the assets are static, they can be served from CDNs, meaning that each end user is served the site assets from the server closest to them. This is combined with instant cache invalidation when a new version is released, and users always get the most up-to-date version of the site from the CDN.
• Jamstack sites scale by default – You don’t need to spin up additional servers to accommodate heavy traffic load when your site is being served from a CDN. Plus, Jamstack sites rely upon services like cloud functions, which are built to scale, for dynamic processing and functionality.

Security

Security is a tough topic to make broad assertions about as there’s no such thing as a completely secure option. A properly patched and maintained WordPress site can be secure, but the reality is that recent data looking at the Alexa top one million sites shows that “73.2% of the most popular WordPress installations are vulnerable.”

These issues aren’t WordPress-specific. Traditional sites have a lot of moving parts that need maintenance and patching regardless of the content management and application framework. For example, a WordPress or Drupal site include things like the PHP web server and the MySQL database. For a Django site, it might be Python and PostgreSQL.

Jamstack sites, on the other hand, benefit from a greatly reduced surface area for attacks. These include:

• No web server to compromise;
• No web application server or web application framework with potentially unpatched security flaws to exploit;
• No database to gain access to;
• No central source of truth to hack because the site is served from multiple CDNs.

Yes, Jamstack sites can depend on third-party services, which can be open to attack. This also gives Jamstack sites the ability to take advantage of the domain expertise of these services. For instance, rather than implementing a custom authentication, they can take advantage of services like Auth0 or Netlify Identity that specialize in authentication and implement industry best practices. Plus, as software as a service (SaaS), there’s no need to worry about patching.

Cost

Ok, let’s get to my personal favorite benefit of Jamstack: they can greatly reduce costs to the point of frequently even being free. Because there’s no need for web application servers and database servers, the costs of hosting the Jamstack are generally negligible to nonexistent. Continuous deployment services like Netlify, Vercel and Render all have generous free plans that can accommodate the needs of many sites and pricing generally scale based on usage or additional features. Some services, like GitHub Pages, offer continuous deployment and hosting for free (with limitations).

The same is true of many of the third-party services that are popular in Jamstack sites – commercial offerings have generous free tiers and entirely free or open source options exist, though typically with some limitations. For example, services like Algolia for search or Sanity for content management, offer free tiers that can make them workable as cost-free or low-cost options for many sites. Meanwhile, tools like Lunr for search and Netlify CMS for content management provide free and open source alternatives.

Services and hosting are two of the places where Jamstack can offer potential savings. Many Jamstack case studies cite reduced development and maintenance costs. For example, a recent Netlify whitepaper cited Loblaw Digital lead time reductions for a single campaign being reduced to “a month instead of the typical year, representing a 10x reduction in time to market, [and] $38,000 monthly cost savings.”

When Jamstack May Not Be the Right Choice

Recently, it has become far more difficult to make a clear-cut recommendation about when to use Jamstack. The improved capabilities of Jamstack tools and services make almost any type of site possible using a Jamstack approach. In fact, tools such as Next.js, make it possible to create a hybrid solution that give developers the option to make some routes static and others server-side rendered. That being said, there are times when a Jamstack approach may not make sense.

1. An application that relies heavily on user-generated content. It’s entirely possible to build user generated content as static assets or pulled via an API. Examples of Jamstack sites adding things like user-generated comments or posts are written to files that trigger a rebuild or pulled dynamically from an API. This can make sense in cases where the user-generated content is periodic and supplemental, but for sites primarily focused on user-generated content, a Jamstack solution may be overly complex and difficult to implement.
2. An application where content is continually updated. Similar to a site with user-generated content, a site with constantly updated content (for example, a real-time news site) may not be ideal for a Jamstack approach. Yes, this content could be updated live via client-side API calls, but this can be difficult to properly implement and may negate some of the overall performance benefits of the Jamstack.
3. A dashboard that relies heavily on server-side processing. Some dashboard applications make perfect sense as Jamstack. In many cases, these dashboards call APIs to populate charts and data tables that make sense to process on the client-side. In other cases this may unnecessarily put too heavy a load on the client and not be an optimal solution.

As you can see, the line for what can be a Jamstack application is blurry. Every one of the examples above can be built as a Jamstack application. I’d think about it in terms of how complex would the Jamstack solution be over a traditional server-side solution, and how much am I offloading content to client-side API calls versus content which is generated as static assets. Don’t over-architect a site to make it fit into Jamstack paradigm as you may find such the solution brittle and difficult to maintain. Don’t offload the majority of your content display to client-side API calls as you’ll find this can negate some of the benefits of Jamstack’s static, CDN-based approach. These are guidelines, not hard and fast rules, but they can help you evaluate if the benefits of Jamstack outweigh the drawbacks for your project. For most projects, I’m certain they will, but in some cases they may not.

Now that we understand some of the benefits of choosing to use the Jamstack you might be asking yourself how you can use it.

The nature of the Jamstack means that there’s no easy answer to that question. A myriad of combinations of tools and services that you can use to create a site that qualifies as “Jamstack.” This is why many books and tutorials about Jamstack tend to gravitate towards a single solution. The goal of The Jamstack Book, however, is to give you the information and “real-world” usage to be able to evaluate what tools and services best meet your specific needs. Let’s get coding!

That’s all for now

If you want to learn more about the book, you can check it out on Manning’s liveBook platform here.