The increasing popularity of JAMstack is a logical consequence of the trends toward serverless architecture, static site generators, and Headless CMS. The term JAMstack was coined by Netlify founders Matt Bijlmann and Chris Bach back in 2015 – a solution, as you can see, that’s not very new. But it’s only now becoming increasingly popular.
To begin with, let’s understand what JAMStack is, what it is, and why it is “superior” to traditional websites. In order not to go into details and not to turn an informational article into a copy-paste from official sources, we will try to describe in a nutshell what JAMstack is.
JAMstack is not a technology. Instead, it is a methodology or approach that offers many tools to choose from for creating static sites. It’s been around for a while, but it’s already gained a decent community.
JAMstack is “J” for JavaScript, “A” for API, and “M” for markup (as it says on the official site).
Based on an abbreviation, it becomes clear that to create a static site, which will not be inferior to the dynamic, we need only three components:
JavaScript – for making our site interactive;
API – the source of information used by the site;
Markup – a kind of content generator or, as some call it, a “templating tool” that allows us to create the markup of our pages.
Many developers praise this approach and believe it is the future of software engineering services. Because this approach lets you create web and mobile applications faster, you have less server and hosting to worry about (everything is set up for you), making scaling solutions easier and cheaper for developers.
The essence of the approach is this:
1. The frontend is separated from the backend and databases and deployed through a CDN (Content Delivery Network) – because of this, sites and applications work faster;
2. All necessary screens are rendered in the process of building as optimized static pages with HTML, CSS, and JavaScript (in contrast, there are dynamic pages that respond to each action of the user) – each new page is created only when you change the code or content, but not under each user request;
3. To link the frontend to the backend, Javascript and APIs are used. It also allows you to improve and personalize pages for the user. API, in this case, implies a source of input information and content to embed into our Markup template.
These can be content files located directly in the content generator; a third-party admin panel that connects to our generator; or a full-fledged REST API for outputting more structured and complex inform
Have you heard that somewhere before? Sounds like server-side rendering, huh? Yes, but no. With the JAMstack approach, the code is sent to GitHub somewhere, and all possible elements are turned into pre-rendered static markup, with files stored in the CDN. When the user makes a request, the browser goes to the CDN, not the server. And with JavaScript and API requests on the static page, “thrown” the necessary dynamic content and personalization for the project. And it turns out that all the operations for displaying the final page upon user request are not on the server side but the client (in the browser), and even more so during the build – there is no need to generate anything on the server or the client.
Explaining JAMstack in an even more straightforward way, the content is created via Headless CMS, the code via framework, and the static site generator is used to link the first to the second.
It turns out that most of the web application’s logic is delegated to the client side, and all the complex functionality, usually requiring time, resources, and knowledge to create it, is implemented through third-party APIs (oh, it’s the aforementioned microservices architecture!). And because of that, you don’t have to worry too much about the logic of the server side. A bonus is lower server response latency and load reduction, which equals the better performance of SaaS applications and sites (Nike and Mozilla seem to be already using this approach).
The trend of JAMstack promises excellent prospects for website and application development because this solution combines the best tools and technologies like React, Webpack, React-router, and GraphQL. It makes the solution attractive to developers: you can use the technologies you like best.
It all sounds fabulously cool. But critics of the approach say that “the JAM stack has taken the worst from static sites, limiting features, and from regular dynamic pages, taking the complexity of development from there.” We don’t like the connection with GraphQL queries nor the work with the Gatsby framework (there are many dependencies within it, which can lead to problems with the inevitable JS updates).
Whether JAMstack is suitable for online stores is a question. For quick startup site creation – potentially yes. But JAMstack seems more like a marketing ploy than some revolutionary tool.