When talking about JAMstack, we think about something so different. That’s not a new thing in actuality. To simplify, We can say that JAMstack combines Javascript, API, and Markup. However, it isn’t easy to have a simple definition of JAMstack.
- We don’t have any installer for JAMstack
- We don’t have any predefined tools to build JAMstack.
- We don’t have a specified language in programming JAMstack.
What is the JAMStack?
So Jamstack is more of an architectural pattern or methodology for creating sites. While there is a lot of ongoing debate about this, these are the critical elements as we define them:
- Built on static assets.
Jamstack sites are always static files. So, when the users request a page, they always get the same static asset. However, this does not mean the content is static. Modern Jamstack sites offer many types of rendering, including fully static and server-side rendering. - Using a static site generator.
The Jamstack site needs an SSG (Static Site Generator) tool to generate the static assets. In general, an SSG takes templates and combines them with content. We can use files such as Markdown, YAML, JSON, or pull from APIs to store contents. After that, the content and template combine to dynamically generate the site’s HTML, CSS, and JavaScript assets. As you can see, that process is similar to the dynamic web server like PHP, NodeJS, Java, etc., but most of this process happens at build time before the site is deployed. - Leverages APIs
Although the Jamstack site runs as static assets, it can be dynamic. By using APIs, they can create dynamic functionality. The browser client can call these APIs at run time or by the static site generator at build time. - Using JavaScript for dynamic functionality.
The second thing to make a Jamstack site dynamic is its ability to call APIs and other services asynchronously on the client via JavaScript. The static assets can change dynamically using JavaScript via Document Object Model (DOM) manipulation.
As this definition shows, there is a lot of flexibility to adapt. We can combine many tools and services that meet the needs of our project and our language, tooling, and deployment preferences.
But, the flexibility has a cost. There’s no single way to teach someone Jamstack, and many options can steep the learning curve for newcomers. Also, there is arguably additional complexity in creating a site that leverages a variety of APIs and services while also dynamically updating content on the client using JavaScript.
So why choose Jamstack? The Jamstack evolved partly to address the problems of a dynamic web that many felt had become slow, costly, and insecure. To better understand the need for the Jamstack, we need to understand how and why it evolved.
The benefits of Jamstack architecture
In early 2020, the team at Netlify, who manage the jamstack.org site, opened a discussion to change how the term was written from JAMstack to Jamstack. Many community members chimed in, and the decision was made to make the change.
As you can see, The JAM acronym showed signs of becoming a source of confusion. Firstly, JavaScript, APIs, and Markup seem like things that could describe almost any site built for the web; the acronym didn’t make clear the difference. Secondly, when we used JavaScript seemed to create the impression that Jamstack was synonymous with JavaScript frameworks and exclusively JavasScript framework-based static site generator tools. Finally, JAMstack is not a “stack” because there is no preset group of tools as in LAMP.
Now, let’s answer the question, “Why do we use Jamstack?”
Performance is the best choice.
When we talk about the performance of Jamstack, we have three things to mention:
- Static assets load faster than dynamic ones: They don’t need any processing to turn dynamic templates into HTML, CSS, and JavaScript, and no database calls at the run time. These assets are pre-rendered, and the page rendering occurs at build time rather than run time.
- Served “from the edge”: The assets are static, and we will deploy them to CNDs. So we can use the advantage of CDNs for caching and delivering content to end-users at the server closest.
- Scale by default: We don’t need more servers to accommodate a heavy traffic load when our site is served from a CDN. Besides that, Jamstack sites rely on services like cloud functions, which are built for scale, dynamic processing, and functionality.
Security is delivered to domain experts.
Regarding traditional sites, many parts need maintenance and patching, including content management and application framework. For example, we must handle the PHP web server and the MySQL database for WordPress or Drupal sites. That will be the same with the Django site; it might be Python and PostgreSQL.
In contrast, Jamstack sites reduce so many attacks from their design.
- There’s no webserver to compromise.
- There’s no web application server or 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.
But how about 3rd parties services, which can be open for attack? However, this also allows Jamstack sites 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), the developer does not need to worry about patching.
The cost is low.
The costs are generally negligible since Jamstack sites don’t need servers to host their web application and database. And some continuous deployment services like Netlify, Vercel, and Render all have generous free plans that can accommodate the needs of many sites and pricing and generally scale based on usage or additional features.
That’s true in many third-party services 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 make them work 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.
When Jamstack may not be the right choice
It’s hard to say how to choose or not to choose. The current development of popular frameworks like Next.js or Gatsby has made the development of Jamstack successful and easy. However, there are some following cases that we can consider.
- An application that relies heavily on user-generated content: We can build user-generated content as static assets or pull it via an API. Mainly, we can trigger a rebuild or pull dynamic from an API when the user comments or posts. That makes sense when user-generated content is periodic and supplemental, but if we do that Jamstack solution may be overly complex and challenging to implement.
- An application with continually updated content: Similar to a site with user-generated content, that is not ideal for the Jamstack approach. Although we can use client-side API calls or SSR to build content, this can be difficult and may negate some of the overall performance benefits of the Jamstack.
- A dashboard that relies heavily on server-side processing: Some dashboards need to call API to build or populate charts and data tables. If we handle all on the client side, we can make it too heavy on load. So that is not a suggestion to do that.
