Debunking JAMSTACK

Hey what’s going on guys, hope you’re all doing well.

I am going to debunk the term ‘Jamstack’ for all of you who have been hearing the word for some time but didn’t really understood what it meant.

We’ll explore together the key principles of the JAMstack to determine if this innovative web development and deployment system is the right fit for your next project.

In recent years, the concept of the JAMstack has gained significant traction among web developers as a modern approach to building websites.

First let us start by the term:
The JAMstack, which stands for JavaScript, APIs, and Markup.
Jamstack represents a shift away from traditional monolithic architectures towards a more decoupled and efficient way of developing web applications.
“Monolithic” refers to traditional architectures where all components of a web application, including the frontend, backend, and database, are tightly coupled together into a single, cohesive unit.

At the core of understanding Jamstack lies the distinction between static and dynamic in the web world.

In the static approach, content is pre-built or precomputed, reducing the need for on-the-fly computation with each request.you have prebuilt assets available whenever the client asks for it and this translates to faster and more cost-effective responses.

However, dynamic involves constructing something on the spot, responding to each request as it comes in, each time you make API call for example, the client sends to the server and the server sends to the database to retrieve data, API json data is being parsed in your fontend framework, to JSX syntax for example then transpilled to Javascript, being embeded in html file and then sent to the end user … you see the difference ?

Now, key static components include JavaScript, audio/video files, and CSS for styling.
But wait, doesn’t JavaScript change a lot? Even though it behaves flexibly on web pages, the actual code stays the same in each update, making it like it’s fixed.
Basic rule of thumb here is: calculate things ahead of time whenever you can to avoid problems with performance, speed and scalability.
If you can precompute the response, that’s going to be better for you and your users.

In the past, web servers had to do a lot of things like

1- Serving [showing] HTML pages,
2- Dealing with static assets/files,
3- And managing API connections.

Nowadays, you can use services like Google Cloud Storage, or IBM Cloud Object Storage or Amazon S3 – for all of your static assets like image files, audio video, css and so on .

Now we can say that those services now can handle static files, so the only job for web servers mainly just show HTML pages.
The logical question here is: Can we make those HTML pages static … precomputed ?

To answer this question, you need to understand how web servers work and how it renders an html page.

1- so let’s say the customer is looking for a certain phone to buy from your website.
so customer enters /phones/smartphone url and hits enter.
this request goes to a web server, the server then connects to an API and asks for the data on that specific phone, and then formats an HTML response about the phone and then sends back to the customer fully rendered.
This approach is called SSR, or server side rendering, because the rendering happens on the server side.
This approach is great for SEO, and the number one framework provides SSR approach is Next.js for example.

2- Over the last decade or so, developers were moving towards client side rendering or CSR.
In that approach, the user makes the same request to the server, but the server but the server responds
with a blank html file with a reference to a javascript application, this javascript application sends the request through the framework, in this case React, then react sends for data query to the API server, which sends back the phone data formatted in json format within the JSX code in your react application, which is being transpilled to javascript back so the browser can understand and fully renders the product data to the user.
This approach is called CSR, or client side rendering, because the rendering happends on the client side.

3- But there is a new way, where during build time meaning in reponse to data changes or code changes, the server goes and gets a list of all phone products from the database, and then uses a set of templates to format in a site that has all that in it, all of those pages are completely prerendered, and those go up to Google Cloud Storage and when the custoemr goes to that page, you imediately get back a page that is completely rendered.

There is the traditional workflow for doing things , where the developer ships the code to server, the server creates HTMl on demand and user get the requested data after a while.

And there is the jamstack or SSG approach which gives us

1- better performance through Faster websites
2- less need for server upkeep like ongoing maintenance for the server, and with that stronger security [you can’t damage a server and its data if it doesn’t exist, right ?]
3- scalability which refers to the ability of your SPA or website to handle increasing traffic or content volume through static site generation, CDN distribution, and serverless functions,and that ensure high performance.
4- better developer experience which makes it easier for us the developers to build and launch websites quickly, thanks to faster development and deployment processes.

JavaScript, APIs, and Markup.

Jamstack is a relatively new term, but the technologies involved are not new at all, JavaScript has been around since 1995 and we all use JavaScript whether in the frontend or the backend with node, APIs which is in everything now, in fact APIs originated from 1940s although the term was well recognized between the 60s and the 70s, so it’s old, and finally markdown in 2004.

Also I read once on twitter someone says Jamstack is a technology, well that’s not correct, it’s rather an architecture, a philosophy or an approach if you will, simply it’s a way of doing things differently with older technologies that we have already.

Furthermore, there are now a lot of options for using JAMstack.
Static Site generators like nextjs, Hugo, Jekyll, Gatsby, and services like Firebase hosting by Google, Github pages, also surge which is a CLI to deploy static sites to global CDN, of course Netlify and Vercel .. so all of those services make it easier for anyone to build and deploy websites using this approach.

JAMstack isn’t just for specific types of websites or technology.
Whether you’re making a simple website or a complex one, JAMstack can work well.
And while services like Netlify and Vercel are helpful, you don’t need them to use JAMstack.

If you want to start using JAMstack, you should first think about what your website currently does and how you can change it to fit the JAMstack way. It might take some planning and changes, but the benefits of JAMstack make it worth considering.

Thank you for reading.
Best,
Bek