How Jamstack Solves the Problems

@ Pattern

Starting from the Norms of Web Development

To understand what problems the Jamstack architecture solves, we need to review the history of web evolution.

Static Files ~ Server Rendering

In the early days of the web, everything was very simple, requiring only static documents for users to browse. However, as time and demands evolved, web developers needed to “dynamically generate” the content within pages and deliver it to users, known as server side rendering.

  • Maintaining servers around the clock for real-time rendering of web pages not only consumed significant resources but also easily created performance bottlenecks.
  • The server needed to construct new pages for new content each time (poor performance, difficult to cache).
  • Traditional CMS (Content Management Systems), databases, backends, and frontends were highly coupled and intertwined.
  • ⋯⋯

Server Rendering ~ Client-side Rendering

With the maturation of tools and environments, developers began to separate the frontend and backend of web pages and create headless technology, driven by APIs to render data in the browser. However, pushing all rendering tasks to the browser also had corresponding drawbacks, such as:

  • Poor SEO (search engine crawlers cannot effectively render pages in real-time)
  • Complete reliance on JavaScript for page rendering (device performance issues, loading efficiency issues)
  • ⋯⋯

What Problems Does Jamstack Solve?

Jamstack deliver static web pages and enhance dynamic content through integration with external services. It usually pre-renders static pages using a Static Site Generator and stores them in a Content Delivery Network (CDN🔗), with dynamic content accessed via Serverless services or distributed microservices.

For example, Joe created a weather website deployed on a server that renders the latest weather pages in real-time for each request. Even though most content is repetitive, the server still needs to operate continuously to generate the latest pages, causing resource waste.

However, if Joe were to rebuild the application using Jamstack, he could first create a lightweight frontend interface distributed across the CDN for better efficiency, obtaining dynamic data only by accessing external services (The point is that how weather data is processed has nothing to do with the Jamstack; we only care about getting the corresponding results from the API).

JavaScript

The core of modern web interaction. In Jamstack, JavaScript is used to load and display dynamic web content.

API

Jamstack delivers data sources and logic to APIs, integrating third-party services to fetch data, connecting both via API calls.

Markup

Web content is pre-generated statically, including HTML, CSS, and assets. These Markup files can be directly deployed on a CDN, enhancing speed and security.

Conclusion

It’s not easy to understand its advantages from just three terms. If I had to describe it in one sentence, I would say:

Emphasizes pre-generating static pages and decoupling business logic from content to improve website performance, flexibility, and security.

You can see that platforms like Cloudflare🔗, Netlify🔗, and Vercel🔗 are actively promoting this architecture, driving Serverless architecture.

  1. Simple static file era
  2. Dynamic rendering of web pages on the server era
  3. Static rendering of web pages in the browser era
  4. Static rendering of web pages + adding dynamic content through integration with external services, the Jamstack era

Reasons You Should Use Jamstack

  • Security: Content is pre-rendered as much as possible and is independently decentralized, increasing attack difficulty.
  • Cost-effective: Jamstack websites can be distributed across CDNs, leveraging caching to accelerate content delivery and reduce costs.
  • Easy to Maintain: Pre-rendered pages are merely a bunch of static files, theoretically very stable and easy to maintain.
  • Development Experience: Based on widely available tools and conventions, services and data are convenient for dynamic replacement and adjustment.

Reasons You Should Not Use Jamstack

  • Long Build Time - Since all pages are pre-rendered on the server, building a large number of web pages will take a lot of time. Incremental Static Generation🔗 is usually a solution to this problem.
  • More Suitable for Websites with Infrequent Content Changes - Due to the limitations of the Jamstack architecture, it might not meet the needs of certain applications. If there’s a need to dynamically generate a large number of pages, other architectures might be more appropriate.

References