Statically gen­er­ated sites and the JAMstack

There is a bit of a trope, a tra­di­tion, that the first thing that is dis­cussed on a newly founded blog should be how said blog was set up and con­fig­ured. I would­n’t dare break away from this tra­di­tion, and will in due time write down the nitty gritty that went into set­ting up this blog, the things I’ve learned and the gripes I had with the tools used. In this par­tic­u­lar post, though, I’d like to start by talk­ing about some of the rea­sons for choos­ing the par­tic­u­lar tech­nolo­gies that I did.

The JAMstack and sta­tic sites

The web world is sat­u­rated with buzz­words.

“But is it re­spon­sive?”,

“Bro, do you even do re­ac­tive pro­gram­ming?”,

“Have you looked into iso­mor­phi­cally ren­der­ing your app on the server?”.

Okay, fine, no one talks like that, but the point still stands. One buzz­word that’s been gar­ner­ing a lot of at­ten­tion the last cou­ple of years is the JAMstack.

Traditional web ap­pli­ca­tions are backed by a web server run­ning the ap­pli­ca­tion in the back­ground. The user in­ter­acts with the ap­pli­ca­tion, the ap­pli­ca­tion typ­i­cally stores and re­trieves in­for­ma­tion from a data­base, gen­er­ates a new page based on this in­for­ma­tion, and serves it to the user. There are a lot of tech­nolo­gies in­volved here, and peo­ple have taken to de­scrib­ing par­tic­u­larly pop­u­lar com­bi­na­tions (“stacks”) with cool look­ing acronyms. Some typical ones are

• LAMP (A Linux machine run­ning an Apache server in­ter­act­ing with a MySQL data­base and an ap­pli­ca­tion writ­ten in PHP)
• MEAN (A Mon­goDB data­base, Express.js web server run­ning an Angu­larJS fron­tend, backed by a Node.js ap­pli­ca­tion).

Enter the JAM stack: Javascript, API’s and Markup. That’s right: no men­tion of a server or data­base. Just good old HTML and CSS, livened up with Javascript. All in­ter­ac­tion with back­end ap­pli­ca­tions is ab­stracted away through API calls. Javascript has come so far in the last two decades that many cases that tra­di­tion­ally called for a back-end ap­pli­ca­tion can now be com­pletely con­tained within the browser. If that sounds lim­it­ing to you, you’d ac­tu­ally be sur­prised how much you can achieve with these ba­sic build­ing blocks by out­sourc­ing func­tion­al­i­ties to pur­pose­fully built APIs.

Do you want peo­ple to be able to com­ment on your blog post? There’s a ser­vice for that.

Do you want to have a web­shop? There’s a ser­vice for that.

“But I like the in­ter­face my CMS pro­vides for writ­ing up con­tent”. Write your blog posts in markup in a user-friendly UI.

This ar­chi­tec­ture does away with loads of the prob­lems that come with tightly cou­pling a web­site to an (often mono­lithic) back­end ap­pli­ca­tion.

• It’s far more se­cure. Protecting against at­tacks falls on the ser­vices that pro­vide the APIs you use (I trust the peo­ple at Twitter or Google a whole lot more than my­self on that ac­count)
• It’s far cheaper to host a sta­tic web­page. Platforms like Github and Netlify will host your page for free.
• Expect much faster load times. We’ve done away with the ex­tra steps of talk­ing to the data­base and dy­nam­i­cally gen­er­at­ing the page. One HTML re­quest and the page gets served. Sta­tic pages that don’t rely on a server to gen­er­ate them can also be served from a CDN, so your con­tent does­n’t have to travel halfway across the world.

The canon­i­cal ref­er­ences peo­ple throw around when talk­ing about the JAMstack are Math­ias Biilmann’s (of Netlify fame) ar­ti­cle on sta­tic site gen­er­a­tors (more on which later), and Smashing Magazine de­creas­ing their load time ten­fold by switch­ing to a JAMstack. If you want in depth dis­cus­sions of the plethora of ben­e­fits, I re­fer to them in­stead of re­peat­ing all of them here.

Which brings us to the next topic: the cat­a­lyst that made the JAMstack rev­o­lu­tion pos­si­ble…

Static Site Generators

Part of what made the tra­di­tional web­server+data­base scheme so at­trac­tive is the de­cou­pling be­tween markup and con­tent it pro­vides. Essentially the page lay­out is stored on the server as a tem­plate. As soon as a user re­quests a cer­tain page, the ap­pro­pri­ate con­tent is pulled from the data­base, plugged into the tem­plate and served up. Surely you can’t ex­pect blog writ­ers to hard­code tens or hun­dreds of posts straight to HTML. As soon as they wanted a re­design of their page, they’d have to go around edit­ing the HTML on every sin­gle page.

That sounds pre­pos­ter­ous.

Enter SSGs. There is no rea­son we could­n’t adopt this scheme of sep­a­rat­ing con­tent and tem­plates on the de­vel­op­er’s (or con­tent cre­ator’s) com­puter. One could then just run a com­pi­la­tion step, gen­er­at­ing the sta­tic HTML pages, ready to be up­loaded.

Want to give your web­site a com­plete makeover? Just change the tem­plate and re­com­pile your web­site. Done.

To say the SSG mar­ket boomed over the last cou­ple of years would be a gross un­der­state­ment. SSGs are avail­able writ­ten in vir­tu­ally any lan­guage you can think of, all hav­ing their trade­offs and serv­ing rather spe­cific pur­poses. The list — con­ve­niently kept up to date at Staticgen — is too long for me to bother count­ing.

A cou­ple of the more pop­u­lar ones are (according to Staticgen.com):

• Jekyll: Probably still the reign­ing king in the SSG-land with a mas­sive ecosys­tem of plu­g­ins. Written in Ruby and mainly aimed at blog­ging sites. Part of its pop­u­lar­ity is due to its tight in­te­gra­tion with Github Pages.

• Gatsby: Probably the biggest SSG writ­ten in Javascript. It gen­er­ates web­sites as React apps.

• Hugo: Written in Go, Hugo’s main sell­ing point is speed. We’re talk­ing or­ders of mag­ni­tude. For this rea­son, Hugo is be­com­ing pop­u­lar among big­ger web­sites with tons of pages to be gen­er­ated on every re­build. Smashing Magazines’ leg­endary sta­tic in­car­na­tion is pow­ered by Hugo.

• Hexo: Another Javascript-based SSG. Unlike Gatsby with React, Hexo doesn’t force any frame­work on you. While it’s seem­ingly re­ally pop­u­lar, the bulk of Hexo’s user­base is cen­tered in China. This makes reach­ing out to the com­mu­nity or find­ing ex­tra re­sources harder than some of the other SSGs mentioned here.

None of these par­tic­u­larly ap­pealed to me. I wanted to be able to get my hands dirty if nec­es­sary, and I don’t re­ally have any ex­pe­ri­ence read­ing or writ­ing Ruby or Hugo, so they were out. It’s not like my mod­est blog would ben­e­fit much from Hugo’s high speed com­pi­la­tion. Gatsby forces me to make the web­site into a full blown React app, which again sounded a bit overkill. Hexo sounded like a vi­able al­ter­na­tive, but I wanted to have a lively com­mu­nity to reach out to when needed.

I ended up go­ing for Eleventy, a brand new SSG (when I say brand new, I mean brand new, it was re­leased in 2018) that has been gain­ing a lot of trac­tion in the last year. It is an ex­tremely stream­lined, no-frills gen­er­a­tor writ­ten in javascript that does­n’t force any frame­work on the user. The beau­ti­ful thing about it be­ing Node.js based is that the en­tire NPM ecosys­tem is es­sen­tially avail­able to cus­tomize and con­fig­ure your blog in whichever way you want. In the next post, where I go slightly more in depth into how I set up Eleventy, it will be­come ap­par­ent just how npm is an es­sen­tial part of the Eleventy ex­pe­ri­ence.

Hosting on Netlify

Before, I used to host any per­sonal stuff on Github Pages. Deploying the page is lit­er­ally just a git push. Netlify takes this easy de­ploy­ment and turns it up to eleven. Deployment still just con­sists of a git push, but netlify throws in many ex­tras, like as­set op­ti­miza­tion, SSG com­pat­i­bil­ity (essentially, you tell Netlify how to com­pile your site, and it will do it for you when­ever you push to your repos­i­tory). Netlify’s free plan also in­te­grates with AWS Lambda func­tions, pro­vides con­tin­u­ous de­ploy­ment and pre­ren­der­ing for SEO optimization.

Phew, I hope that was­n’t too much of a sales talk. I’m can’t to see what this mod­ern ap­proach means for pre­sent-day blog­ging.