It’s been a while since I spent any time thinking about frontend web development. Things have changed so much in HTML, CSS, Javascript and development paradigms that a modern codebase is almost unrecognizable from one that’s 10 years old. As I interview front-end candidates for a new position, I’m mostly hearing about the MERN stack (as well as MEAN and MEVN), however, I keep hearing the word “JAMstack” pop up in strange places. My friend and business partner Luca Passani just returned from a front-end conference with a small O’Reilly “book” on the subject (written by Netlify), so I thought I’d give it a read. It was interesting indeed, although I’d say the benefits are greatly overestimated.
The JAM in JAMstack stands for Javascript, APIs, and Markup. Sites are created by using tools like Hugo or Gatsby to scrape your content (from markdown files or another CMS, for example) and produce the entire website out of static HTML files. Everything is on the frontend, there is no backend server at all. All interactions that need a backend are accessed via Javascript, and generally these should be third-party APIs that provide the functionality you’re looking for. To publish a JAMstack site, you simply upload the site somewhere and serve it through a CDN (or use a GitHub post-deploy hook to deploy it for you as Netlify does).
After reading the book, I was curious, but unconvinced. I had this abandoned blog (the one you’re reading) that was more than 10 years old and decided to convert it from Wordpress to JAMstack using Netlify’s Victor Hugo boilerplate and the make-wp-epic utility, which converts a Wordpress blog to front matter markdown files compatible with Hugo.
Overall, I have to say that I am impressed. The system is more mature than I expected, and the problem of regenerating the entire site on every change is totally mitigated by the tooling, which rebuilds the site automatically in milliseconds. Although this seems like an exercise in maximizing over-engineering, the reality is that this type of tooling is already required for everything else that you care about anyway (Javascript transpiling, CSS compiling, minification, etc). I found Hugo to be quite nice although there seems to be less convention than I’d like. The location of folders and files seems to diverge in the many popular boilerplates, leading to weird problems integrating themes. In the end, I found it to be a valuable exercise and I’m going to stick with JAMstack for my personal blog. It also seems like a good choice for other content-rich sites that don’t have lots of dynamic content. You can certainly have dynamic content on JAMstack, but you have to do everything in Javascript, which you pay for in web performance. If you haven’t run into JAMstack in the past, I’d suggest giving it a look!