JAM Stack and SPA, CSR, SSR
#frontend
Table of Contents
- What is JAM Stack?
- How is JAM Stack different from SSR/CSR?
- Does this mean SSR is no longer necessary?
1. What is JAM Stack?
- J: JavaScript
- A: API
- M: Markup
JAM Stack refers to a web architecture consisting solely of JavaScript, APIs, and Markup (HTML).
It shares similarities with Single Page Applications (SPA) but differs in some important ways.
JAM Stack is not tied to any specific technology (e.g., React, Vue), but rather represents a way of structuring a website using these technologies.
JavaScriptAll client-side processing is handled by JavaScript.
API
All business logic and functionality are abstracted into reusable APIs.
Markup
Markup (HTML) is pre-generated using Static Site Generators (SSG) or Template Engines (e.g., Webpack).
A similar stack would be the
MERN Stack, which consists of:- M: MongoDB
- E: Express
- R: React
- N: Node.js
2. How is JAM Stack different from SSR/CSR?
Before modern web frameworks and libraries like React, Angular, or Vue, websites were typically rendered using SSR (Server-Side Rendering). SSR involves receiving a request from the browser and sending back HTML content to be rendered by the browser. However, SSR can be inefficient compared to CSR (Client-Side Rendering) because it requires more server resources.
Additionally, CSR is generally more efficient in terms of speed since the browser renders content directly without needing to go to the server each time a page is visited. In CSR, only the necessary resources are fetched through HTTP requests, and the view is updated in the browser using JavaScript and CSS.
In a typical SPA (Single Page Application), HTML is minimal β usually containing just the
<head> and basic <body> elements, with JavaScript dynamically rendering the content. This allows SPAs to move away from the server-rendered HTML model and instead rely on client-side JavaScript and APIs for rendering.Key Differences:
- SSR: The server is responsible for rendering HTML, which can be resource-intensive and slower.
- CSR: The client handles the rendering, which allows for faster page transitions and less server dependency.
3. Does this mean SSR is no longer necessary?
While CSR via SPA has many advantages, it also comes with two significant drawbacks:
- Initial load delay: Before the first meaningful content is displayed, CSR often experiences a delay.
- SEO limitations: Since the HTML is mostly empty, itβs harder for search engine bots to crawl the content, making SEO optimization difficult.
Despite these drawbacks, CSR is still an appealing architecture, and to address these issues, solutions have been developed.
For example, frameworks like Next.js (for React) and Nuxt.js (for Vue) implement a hybrid approach.
They use SSR for the initial page load, rendering the first page as complete HTML, which addresses the first issue (by improving First Meaningful Paint speed).
Then, after the page loads, JavaScript is used to take over and render the rest of the page, improving the SPA experience. This hybrid approach also resolves the second issue, as search engines can crawl the pre-rendered HTML, boosting SEO.
In summary, SSR is still relevant, especially in hybrid frameworks where it is used to improve performance and SEO while maintaining the benefits of CSR for the rest of the app.