Every so often, web development takes a dramatic turn for the better. In this article, we introduce the Jamstack, explaining what it is and why it’s great.

Back in the day, dynamic sites exploded with the LAMP stack. Then the MEAN stack provided a foundation for the next generation of web apps. Now that APIs and reusable components are on the rise, static sites are fashionable again. It’s a “back to basics” of sorts — but not quite.

What Is the Jamstack?

Provided: Netlify

The Jamstack is a redefinition of the modern web for faster and more secure websites. These sites scale better and, with the proper toolset, are a lot easier (and more fun) to develop and maintain.

Let’s break up the term:

• J stands for JavaScript. JS has come a long way since it was introduced by Netscape in 1995. With reactive and progressive libraries, you can design web apps that behave pretty much like mobile ones.
• A stands for APIs. You don’t need to program every single functionality yourself, but can rely on third-party processing for a huge number of tasks.
• M stands for Markup. You can reuse components that have already been developed, or create new ones that are a lot easier to maintain.

Isn’t that just buzz?

In a way, yes. The term Jamstack, originally stylized as JAMstack, was coined by the company Netlify as a way of promoting their “all-in-one platform for automating modern web projects.” The principles behind the Jamstack aren’t really new, as web components and APIs have existed for quite some time.

But in very much the same way the term Ajax (asynchronous JavaScript and XML) was coined by another company back in the day — Adaptive Path — and even though the XMLHttpRequest (XHR) API that made Ajax possible also existed for some time, both Ajax and JAMstack were a refreshing revamp of ideas with legitimate uses that were quickly adopted by the community. The hype is well-deserved: this way of working has been a revelation for many developers around the world.

Static sites?

“Static sites” are the antithesis of “dynamic websites”, right? So how to provide rich and dynamic interaction with just plain HTML files? Well, JavaScript.

JavaScript has evolved a lot since the first browser wars, having consolidated itself as a general-purpose programming language with the advent of Node.js, and with libraries like React, Angular and Vue.js. The possibilities for designing high-grade user interfaces (UI) are endless.

Of course, JavaScript isn’t a silver bullet. You most probably won’t be doing data analysis or AI with it. But for web development, there’s hardly anything that you can’t do with an API that you can consume with JavaScript methods, as chances are that somebody already created a microservice for it.

And if, on top of that, you could “encapsulate” all of that process with markup into a reusable component — which you could pretty much drop-in whenever you need that specific functionality — you could potentially save hours of work every time.

That’s the J·A·M stack right there: JavaScript, APIs, markup.

Decoupled, Headless, Microservices, Serverless… Sorry, What?

All of these are hot topics in web development, and they’re all closely related but not quite the same. You’ll hear these terms a lot, so let’s clarify some terminology right form the start.

Coupled vs. Decoupled vs. Headless

COUPLED is when the content of a website is created, managed, and stored on the site’s back end, where the database lies (such as the WordPress admin). This content is then pulled from the back end and represented in the browser through a front-end interface (such as a WordPress template). In a way, a “coupled” application is the traditional “full-stack” with the back-end and front-end being different sides of the same app.

In contrast, DECOUPLED is when the back end and the front end are managed separately — meaning that the database and management tools will be on one server, and the front-end somewhere else. Naturally, there needs to be a medium by which both are connected, which is normally an API. What’s more, since the back-end now is effectively separated from the front end, there could be, in fact, several front ends in different locations! (Think of different storefronts using the same engine, such as Shopify.)

In a nutshell, HEADLESS software simply doesn’t have a front-end or a presentation layer. A headless CMS, for example, is one that could generate static content and push it anywhere: a mobile app, an Internet of Things device, a static website. Admittedly, this is also a “decoupled” situation, but here you might not even need an API. Think of a WordPress engine that exported its posts to be served as static HTML files: that’s headless. In fact, you’re on a page that was generated in exactly this way right now.

Monolithic (Tightly Coupled) vs. Microservices (Loosely Coupled)

Put simply, MONOLITHIC could be defined as software that’s built in one piece. Examples might include a mobile app, most applications that you can install on your computer, and web apps such as WordPress. These apps can still have internal “modules” or “components”, but we say these are tightly coupled because they’re an indispensable part of the application, without which the application wouldn’t work.

On the other hand, LOOSELY COUPLED software components work more like plugins that can be removed or replaced, and maybe the functionality will change but the core of the application will still work. This principle enables the “outsource” of functionality through third-party APIs — often called “microservices” — as they provide secondary features (image resizing, login, storing) that aren’t in and of themselves an indispensable part of the application.

#javascript #api #developer