JAMstack vs traditional monolithic workflow

Exploring the JAMstack Workflow and Its Advantages

In this comprehensive article, we will delve into the JAMstack workflow, offering a side-by-side comparison with the traditional monolithic workflow. We will also clarify the distinction between JAMstack and SPA (single-page application). To provide a deep understanding of these concepts, we will break down this content into five key sections:

1. The Shifting Landscape of User Experience

The landscape of user experience is constantly evolving, with mobile devices playing a prominent role. As per a report from wearesocial.com in January 2020, approximately 53% of web page requests originate from mobile phones, while computers account for 44% of the total requests. This statistic underscores the increasing dominance of mobile usage over the years.

Mobile users, much like the majority of us, tend to be impatient. Waiting for a page to load, encountering an initial white screen, or staring at a loading indicator for an extended period is something they dislike. However, it’s essential to consider that the mobile and computational capabilities of devices vary based on factors such as the economy, location, and income.

While some users are still using single-core mobile devices, others have high-end smartphones with powerful hardware support. Regardless of the device’s capabilities, speed remains a fundamental expectation. Interestingly, users with high-end mobile devices are even more impatient because they are accustomed to a fast and responsive environment.

As application developers, it’s crucial to take this user expectation into account when designing the user experience. Our primary goal should be to ensure that web pages load quickly, delivering the necessary initial page information promptly to reduce the dreaded cold start.

2. Prebuilt Markup: The Key to User Satisfaction

One of the fundamental principles of JAMstack is the necessity of prebuilt markup. This concept involves developers dedicating a few extra seconds during the application’s build phase to prevent customers from experiencing frustrating delays at runtime. The beauty of this approach is that customers won’t even notice the additional time spent during the build process.

In a typical user’s mind, when an application loads and a flurry of activities happens within the browser, a significant amount of time is consumed. This extended loading time can easily lead users to bounce off the application or website. Moreover, it fails to meet users’ expectations concerning the design and performance, which can result in a production nightmare.

With the prebuilt approach of JAMstack, many of these issues can be mitigated. All essential JavaScript, markup, and styles are already prebuilt and served from a content delivery network (CDN). This approach eliminates the uncertainty of waiting for scripts and pages to load in the browser at runtime.

The heavy lifting, which traditionally occurs during runtime, is done at once during the build process. This strategy reduces the processing time required at runtime, resulting in a smoother and more responsive user experience.

3. Comparing Build vs. Load Times

To appreciate the benefits of prebuilt markup in JAMstack, it’s essential to compare the build and load times across different web application architectures. We’ll explore the differences between server-rendered applications, single-page applications (SPAs), and JAMstack.

Server Rendered:

In a server-rendered application, the server handles all the computational heavy lifting. The browser sends a request for a page, and the server calculates and generates the page content. Once the page is ready, it’s sent to the browser as part of the response. The browser then downloads and renders the page. This cycle repeats for each new page request, creating consistent communication over the network.

Single Page Application (SPA):

SPAs tackle the computational load differently. The server is no longer responsible for page computation, routing, or request-based serving. Instead, the browser and device handle all computations in real-time.

JAMstack:

In the JAMstack approach, content is prebuilt, eliminating the need for an origin server. Content is served directly from a CDN, addressing the issues seen in both server-rendered applications and SPAs.

4. Leveraging the Benefits of Prebuilt Content

Prebuilding content in JAMstack applications offers several advantages, including:

• Transpiling JavaScript and building it alongside markup and styles.
• Pulling data from remote services.
• Compiling C into WebAssembly.
• Linting your code for accessibility (Netlify has introduced a build time plugin system, which will be explored in a future article in this series).
• Shaping data for UI components during the build process.

This approach also addresses the rollback issue discussed earlier, which will be explained further in this article.

5. The Role of Content Delivery Networks (CDNs)

Now that we understand the benefits of prebuilding content, it’s crucial to delve into the significance of Content Delivery Networks (CDNs). The advantage of prebuilt markup is fully realized when a CDN is integrated into the architecture. Without a CDN, the experience would be nearly identical to server-rendered applications.

To illustrate this point, consider a scenario where an origin server (e.g., abcd.com) serves the application content from a location in the USA. If a user from a distant location like India attempts to access a page from abcd.com, their experience may be subpar due to factors like network speed, hardware capabilities, and the physical distance between the user’s browser and the origin server.

This is where a CDN comes into play:

• CDN reduces the distance between users and website resources. It caches content in multiple locations, ensuring users can access data from a nearby server.
• CDN reduces data transfer through techniques like minification. This results in faster loading times and reduced data usage.
• CDN helps with cache invalidation, ensuring users do not encounter outdated or stale data.
• CDNs provide enhanced security, protecting both the content and user interactions.

Traditional vs. JAMstack Workflow: A Comparative Analysis

To summarize the critical differences between traditional and JAMstack workflows:

Traditional Workflow:

1. Developers write, test, and build the application.
2. The application is shipped to a server (origin server).
3. Users request resources from the origin server via URLs.
4. The origin server handles computations, generates HTML, and sends it to users.

JAMstack Workflow:

1. Developers write code and push it to a source repository like Git.
2. A workflow is initiated, triggering the build process to create prebuilt content.
3. The prebuilt content is deployed to a CDN.
4. Users access resources directly from the CDN, serving the prebuilt content without involving the origin server.

JAMstack makes it easier to manage customer expectations and facilitates quick fixes and rollbacks. This is in stark contrast to the traditional approach, which requires elaborate planning, involving developers, testers, and DevOps, and a full application rebuild before deploying changes.

What’s Next?

With this foundation in JAMstack principles, the next article in this series will explore the use of Static Site Generators (SSGs) in combination with Headless CMS, offering a more comprehensive understanding of this innovative approach to web development. Stay tuned for more insights and practical applications of JAMstack in the upcoming articles.