The Evolution of Jamstack (opens in new tab)

I agree. The importance of separating presentation concerns from business logic was in the air, impossible to avoid, when I became a software engineer in the early 2000s.

> At that point [in 2016], the idea of fundamentally decoupling the front-end web layer from the back-end business logic layer was only an early trend, and not yet a named architectural approach.

The first named architectural approach I ever learned was three-tier application architecture (presentation, business logic, database,) named to contrast it to the two-tier approach of combining the presentation logic and the business logic in a single layer (often a desktop application that communicated directly with a database.) The problems arising from this mixing and the advantages of separating UI and business logic into different architectural tiers were well known to people writing internal business applications long before web applications took over this niche. I don't know the history prior to my own introduction to the industry, but I wouldn't be surprised if it dated back to the mid-1990s or even earlier.

100% this. APIs have existed and served content to front ends waaay before the term Jamstack was coined. The author seems to be over applying what is actually a narrow flavor.

I tend to agree. Rise of JAMStack as a concept is likely backed by companies like Netlify, Vercel, Auth0, Twilio, Firebase, and very other API-as-a-service company.

Though I think its part natural evolution of how web apps are built - it makes sense that common web apps functionality (like auth, database, email, etc) would be commoditized as services. I don't see that as a bad thing, especially since there is a lot of open source software (RoR, Django) that commoditizes and standardizes those aspects anyway.

JAMStack also has the side benefit of encouraging developers to focus on the business value of the software they are building, rather than the underlying plumbing.

It's sort of funny to see how this has suddenly become such a big term. I started out building a CMS that deploys static sites. I did that because I didn't want to deal with DBs / Wordpress, etc. I just wanted to quickly throw static pages onto a CDN and not worry about hosting. Netlify and the likes enabled this and I thought it was rather fantastic. So easy to deploy, very little performance worries, no DB to secure etc. etc. Then the JAMStack term started showing up (pushed by Netlify initially, I believe?). And you're right, just like 'serverless' (which is a ridiculous misnomer), I think this is just the kind of thing that's needed to get non-technical people on board with a better way of doing things.

At the same time, I think there's true advantages to this approach, so long as you do things right and don't fall into the traps of paying through the nose for things that should be cheap. cough Netlify form handling.

The challenge for Netlify (and my own business as well) is finding a way to capitalise on static sites, so often they will decide on some arbitrary metric and restrict that.

So, while I think the term jamstack may go away, I feel the idea behind static sites probably won't. To be able to make a whole shop, including financial transactions, without a DB in sight is quite appealing imo.

Just don't get suckered into the walled gardens / closed ecosystems out there.

This is also true for basically all "cloud" services. There's no real innovation, just a return to mainframes and timesharing with a massive amount of marketing momentum to convince everyone that this is a step forwards. But hey, we all drank the Kool-Aid.

After so much time wasted with all of this, SPAs, microservices, microfraneworks, etc, I've ended up pretty burned out of the amount of work it takes, and the incredible number of corner cases I've found. From development environment issues to how to have a staging or testing environment to how to do authentication. Do many things you get for free with more traditional approaches.

Last year we started at work a project with plain old Rails. This year we started using stimulus and turbo. You cannot believe how much our lives have improved. Things are so easy and feel so solid. Everything has documentation, things don't change every other day. Patterns are clear, libraries well tested, we focus 99.9% on actual business problems.

Two members of the team left because they wanted to react node monorepos all the things. It's. South they left, but overall we are so much happier and more productive now, even with two members less (team of 6).

I really wish the pendulum swings back, as they say, and we stop this madness. At least for the 95% use cases that don't need to be an SPA with a Go backend for google scale.

Hmm, so basically you're saying it's a scam right?

It helps if you separate the first three letters:

JavaScript + APIs + Markup = JAMstack.

Markup is the content, which can be entered via any method. You can set up a CMS like WordPress or Ghost to serve this role, or you can build your own interface. That markup is then made compatible with various JavaScript libraries via APIs.

But it evolved over the years to the point where "JavaScript" part isn't entirely accurate. You can throw any static site generator in the mix and just use a plugin that will convert content edited via CMS into Markdown files.

It's basically a way for front-end developers to not particularly care about the backend. So instead of making WordPress themes or whatever they make a site using static site generators. Users don't like the look of an editor? You have the ability to change it completely, find a plugin, and the end result is the same website. No need to adapt the theme to the new CMS or bother with migrating content between editors.

I can at least answer this for my 'Jamstack' product (I think it might be accidentally 'Jamstack', as I only recently found out that this refers to static pages with no DB etc).

I wanted to just have a sensible frontend for Hugo, with easily reusable components that are not React, etc.

So, your questions:

> how does the database fit into this?

The only DB we have is our own CMS, so that's keeping your user details and your site details. That's it. The websites the CMS produces go straight to Cloudflare as static sites. The files sit on our server and are manipulated directly from within the CMS.

> how does the 'Jamstack' compare to Wordpress or it doesn't?

We don't have themes, or drag and drop block-based editing. We use modules (basically components) that combine different ways of displaying text / imagery / video and can be stacked vertically into a static website. All of this runs a lot faster, as we don't have a super complex react frontend with a million loc of JS, but rather just some vanilla js sprinkled in here and there to keep things a bit dynamic. Also works really well on mobile, which Wordpress doesn't do all that well I don't think. Makes it a lot easier to represent site structure visually imo

> how does content get edited in the 'Jamstack' like Wordpress?

A bunch of json files / go html templates fed into Hugo, which compiles a static site. These json files are of course represented in a very visually appealing (I hope at least) way. The whole point of the CMS is to keep all technical concerns far, far away from users.

> how is the 'Jamstack' 'mainstream'? compared to what?

I am not sure it is. Everyone I've so far spoken to is only aware of Squarespace, Wordpress (they claim they're 40% of the web), Wix, or the site builders that come with 123reg or Godaddy. And almost nobody seems to like them, which is a real shame. I think that entire sector has failed to enable laypeople to make websites. I hope to somehow be able to rectify that.

> why do I have to use Git to use the 'Jamstack'?

I think it's for CI (continuous integration) convenience. The problem is that only developers understand how this works. We actually started out deploying to Netlify via git, but the process was too slow and brittle (often webhooks wouldn't work). Thus, we just deploy static sites directly to Cloudflare workers sites. No git involved. Netlify also supports .zip file deployments FWIW.

I found quite the opposite.

Both Next.JS and Gatsby are so so fast with HMR, I really am not sure how they achieve that with Webpack. I have a few apps that are bootstrapped with Webpack and things like hot reloading take a few seconds, with Next or Gatsby it's instant.

As far as build time I've noticed all my React apps, whether built with regular Webpack or Next, all compile in roughly the same time.

Of all the valid criticisms of JAM, this isn’t one.

Not every website is in the hands of marketing people and even if it were so, any CMS can be used. No need to teach anybody how to use Git.

They render HTML on the server. Revolutionary idea.

No, it's more like server side rendering with PHP or Ruby, back in the days.

I wrote a bit about this topic here: https://dev.to/fllstck/where-when-should-you-render-your-htm...

At the end of your SPA build process, you spin up a dummy HTTP server and run headless chromium on it (e.g. with puppeteer) to render each route and save the output html.

Instead of only /dist/index.html, you have /dist/index.html, /dist/about/index.html etc.