A few years ago, some friends and I had the ambitious plan to run a blog. Four people eager to write. Of course we would find the time to publish articles on a regular basis — right?
Back then I was new to web development, and my only mentionable experience with advanced web development software was HTML5 Boilerplate, which shipped with a fantastic build system written in ant (yep – it’s Java-based).
Backbone.js was about to become a thing. Lodash and Underscore.js competed for world domination. My friends and I, we decided to use Jekyll to build our blog, and to use GitHub’s brand new gh-pages feature as a free hosting solution.
Our blog project 4waisenkinder.de is now four years old. We made it to 22 posts; not too bad, but looking back I have to admit that I’m pleased that my current private blog runs on a different setup. I still believe in static sites, because they’re secure (there is no server to be hacked) and fast (there is no server computation involved).
Let’s have a look at what’s changed over the years and how new static site generators like GatsbyJS (based on React), nuxt (based on Vue.js) and next (based on React) are changing the static site landscape and make going static even more popular than it was four years ago.
Finding good developers is already difficult. Finding someone proficient in more than one programming language is even harder.
I’m not saying that these developers don’t exist; just that having one person able to code the statically-generated and dynamic parts in the same language can save a lot of time and spare us from future headaches.
Different languages have different ways of expressing templates, and they are usually incompatible (you can make it work though). From time to time, the "template duplication" led to errors when developers forgot to update both areas, which led to frustration.
With an isomorphic interface that enables you to run your code whereever you ship it (server and browser) saves you work and helps you to avoid errors.
The traditional goal of a static site generator is to render HTML. You define some input files, most likely in markdown, and it will generate some HTML files.
Additionally, a custom setup might work fine for your personal website, but running a completely custom build process always comes at a cost. If you’re building a large-scale site with several developers, what you want to have are code conventions, automatic code linting and well-written documentation to get new developers up to speed quickly.
And let’s be honest with ourselves here: in 99% of the cases, a project with thousands of downloads on npm will have fewer bugs, more features and will be better documented than a self-baked solution.
Another selling point for React and Vue is that the ecosystems are incredibly rich. We’re almost at the stage where the solution can always be "just install another component." Looking for a tabs component in React gives 382 hits and in Vue 77 hits on npm.
Of course, this doesn’t mean that all of these projects are in perfectly good shape, but having any sort of codebase to draw inspiration from can help you with problem-solving and finding an approach that works.
PWA, offline-first, service workers – these were big buzzwords last year. I bet that not everyone has found the time to play around with these new technologies yet, but here’s the catch: with the latest Safari update, progressive web apps are coming now to iOS; meaning they’re more or less cross-browser supported and becoming mainstream – for real!
How much does it take to make your Gatsby site an offline-ready app? Nothing – Gatsby ships as a progressive web app by default!
How much did it take me to make my personal blog a progressive web app? Just 10 minutes for me to install the right plugin tailored to the Nuxt framework. I had initially written the service worker implementation myself and, believe me, it was good fun and I learned a lot – but in comparison, installing a plugin tailored to my static site generator that just works is priceless!
Another flaw of common static site generators is they are usually based on a simple data model that includes only posts and pages – not very handy when dealing with complex data sets.
The moment when your site grows and begins to include data from sources like Github to display statistics of your side projects or Contentful as a content infrastructure, data complexity and requirements will increase.
The needed process won’t involve just the transformation of markdown files to HTML anymore.
How do you bring in API data into your static site generator? There are two ways:
Someone writes an integration for the tool of your choice
You fetch the data and write it to files yourself
Both approaches come with several downsides.
If your static site generator needs an integration for the API provider of your choice, you immediately depend on people maintaining this integration. In my opinion, this is the wrong approach because the power of an API is that data is only one HTTP call away. It should be right at my fingertips without the need for additional tooling.
If you decide to write the needed data to disk in a format that your tool understands, you’re moving the maintenance burden onto your side, which gives you more control but still – transforming JSON to markdown or YAML just to read it later with a different tool feels wrong to me.
Looking at the development flow in this setup you’ll see that this approach is also far away from being optimal:
Fetch data from the API
Write all the data to different files
Run static site generator to render HTML
To see the latest changes, new files have to be written and when you’re dealing with having to generate more than a thousand pages, it will take time and slow development down drastically.
There is also no need for plugins – fetch the data, whenever or wherever it’s needed. Need specific information from one SaaS provider in the header and facts from another provider in the sidebar? No problem – include another data-driven component, and you’re done!
What about development flow? Nuxt and Next, for example, ship with a ready to use development server. This server generates the HTML on-the-fly when you put in a request (making API requests on the server-side) while being able to fetch all the needed data during build time when you want to go static and supporting hot-reloading. This is very developer friendly!
With these new tools at hand, what stays is the question: where you will host your static site in 2018.
These services let you easily connect your GitHub repo, define a build script, then get a generated static site, delivered by a fast content delivery network in a matter of minutes.