
By Ben Lipkin on in Development
More Flexible, Modular Site Development With JAMstack
JAMstack! If you have any exposure to web development, you’ve probably encountered this term. What started as a niche engineering methodology is now a mainstream phrase on the tip of everyone’s tongues, from project managers to account executives. But what is it, and does it make sense for your next project?
The JAM in JAMstack is an acronym—JavaScript, APIs, and markup—that refers to a general approach to web architecture. It aims to simplify site delivery by removing the excess code and server processing inherent in a CMS, and replacing it with premade, static HTML files, often produced by static site generators. The result is a site that can be served quickly by inexpensive servers and CDNs that don’t require extra backend computing. When more involved data-driven features are needed, such as authentication or dynamic content, the goal is to use APIs and third-party services that can load in the background after meaningful content is delivered.
There’s a lot of value in this approach. While speed and security are generally top of mind, decoupling your site’s features is also important and can help your platform stay flexible as your needs change. Say, for example, you want to switch to a new content platform but keep your ecommerce experience. In some scenarios, it may not be possible to give up one without the other. Using separate services that can be encapsulated into modular site components, however, will go a long way toward ensuring you don’t get locked into one system. More and more, vendors are providing solutions geared toward this architecture.
So why wouldn’t you use this approach? The short answer is that like any purpose-built custom product, development can be slow and costly. Even as the JAMstack approach gets smoother and easier to adopt, working with APIs requires seasoned developers to wrangle third-party services and navigate complex JavaScript frameworks. If your project is full-featured but lacks development resources or is only intended to live a short life, the plug-and-play convenience of a CMS is hard to beat, especially as caching and security software continues to improve.
But the decision to use this approach doesn’t necessarily need to be black and white. For example, if your team likes WordPress for managing content, or your developers prefer traditional HTML templates, you could adopt a hybrid approach, using a CMS behind the scenes as a static site generator. In fact, FATFREE uses this approach for our own site. Our team has private access to a CMS with conventional themes and features, but the pages that reach our visitors are static HTML files served independently.
JAMstack is ultimately a developer-centric strategy. It prioritizes craftsmanship, modern workflows, and conceptual efficiencies that may not always align with short-term business interests. To decide if this approach works for your project, first consider whether you have the necessary development resources. Because content is often deployed through code repositories and CDNs, experienced developers will be crucial in crafting smooth workflows that meet your needs. Next, try to think about the lifecycle of the project. If flexibility and scalability are more important than short turnaround times, static files and third-party services might support a longer product evolution as features, vendors, and site traffic changes. Finally, if security, speed and high availability are your biggest priorities, static files and the JAMstack methodology should be at the top of your list.