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