There is a bit of a trope, a tradition, that the first thing that is discussed on a newly founded blog should be how said blog was set up and configured. I wouldn’t dare break away from this tradition, and will in due time write down the nitty gritty that went into setting up this blog, the things I’ve learned and the gripes I had with the tools used. In this particular post, though, I’d like to start by talking about some of the reasons for choosing the particular technologies that I did.
The JAMstack and static sites
The web world is saturated with buzzwords.
“But is it responsive?”,
“Bro, do you even do reactive programming?”,
“Have you looked into isomorphically rendering your app on the server?”.
Okay, fine, no one talks like that, but the point still stands. One buzzword that’s been garnering a lot of attention the last couple of years is the JAMstack.
Traditional web applications are backed by a web server running the application in the background. The user interacts with the application, the application typically stores and retrieves information from a database, generates a new page based on this information, and serves it to the user. There are a lot of technologies involved here, and people have taken to describing particularly popular combinations (“stacks”) with cool looking acronyms. Some typical ones are
- LAMP (A Linux machine running an Apache server interacting with a MySQL database and an application written in PHP)
- MEAN (A MongoDB database, Express.js web server running an AngularJS frontend, backed by a Node.js application).
Do you want people to be able to comment on your blog post? There’s a service for that.
Do you want to have a webshop? There’s a service for that.
“But I like the interface my CMS provides for writing up content”. Write your blog posts in markup in a user-friendly UI.
This architecture does away with loads of the problems that come with tightly coupling a website to an (often monolithic) backend application.
- It’s far more secure. Protecting against attacks falls on the services that provide the APIs you use (I trust the people at Twitter or Google a whole lot more than myself on that account)
- It’s far cheaper to host a static webpage. Platforms like Github and Netlify will host your page for free.
- Expect much faster load times. We’ve done away with the extra steps of talking to the database and dynamically generating the page. One HTML request and the page gets served. Static pages that don’t rely on a server to generate them can also be served from a CDN, so your content doesn’t have to travel halfway across the world.
The canonical references people throw around when talking about the JAMstack are Mathias Biilmann’s (of Netlify fame) article on static site generators (more on which later), and Smashing Magazine decreasing their load time tenfold by switching to a JAMstack. If you want in depth discussions of the plethora of benefits, I refer to them instead of repeating all of them here.
Which brings us to the next topic: the catalyst that made the JAMstack revolution possible…
Static Site Generators
Part of what made the traditional webserver+database scheme so attractive is the decoupling between markup and content it provides. Essentially the page layout is stored on the server as a template. As soon as a user requests a certain page, the appropriate content is pulled from the database, plugged into the template and served up. Surely you can’t expect blog writers to hardcode tens or hundreds of posts straight to HTML. As soon as they wanted a redesign of their page, they’d have to go around editing the HTML on every single page.
That sounds preposterous.
Enter SSGs. There is no reason we couldn’t adopt this scheme of separating content and templates on the developer’s (or content creator’s) computer. One could then just run a compilation step, generating the static HTML pages, ready to be uploaded.
Want to give your website a complete makeover? Just change the template and recompile your website. Done.
To say the SSG market boomed over the last couple of years would be a gross understatement. SSGs are available written in virtually any language you can think of, all having their tradeoffs and serving rather specific purposes. The list – conveniently kept up to date at Staticgen – is too long for me to bother counting.
A couple of the more popular ones are (according to Staticgen.com):
Jekyll: Probably still the reigning king in the SSG-land with a massive ecosystem of plugins. Written in Ruby and mainly aimed at blogging sites. Part of its popularity is due to its tight integration with Github Pages.
Hugo: Written in Go, Hugo’s main selling point is speed. We’re talking orders of magnitude. For this reason, Hugo is becoming popular among bigger websites with tons of pages to be generated on every rebuild. Smashing Magazines’ legendary static incarnation is powered by Hugo.
None of these particularly appealed to me. I wanted to be able to get my hands dirty if necessary, and I don’t really have any experience reading or writing Ruby or Hugo, so they were out. It’s not like my modest blog would benefit much from Hugo’s high speed compilation. Gatsby forces me to make the website into a full blown React app, which again sounded a bit overkill. Hexo sounded like a viable alternative, but I wanted to have a lively community to reach out to when needed.
Hosting on Netlify
Before, I used to host any personal stuff on Github Pages. Deploying the page
is literally just a
git push. Netlify takes this easy deployment and turns it
up to eleven. Deployment still just consists of a
git push, but netlify
throws in many extras, like asset optimization, SSG compatibility (essentially,
you tell Netlify how to compile your site, and it will do it for you whenever
you push to your repository). Netlify’s free plan also integrates with AWS
Lambda functions, provides continuous deployment and prerendering for SEO
Phew, I hope that wasn’t too much of a sales talk. I’m can’t to see what this modern approach means for present-day blogging.