The new era of static sites – how JavaScript powers everything (#blogPost)

A few years ago, me and some friends had the ambitious plan to run a blog. Four people eager to write, and 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 and my friends and me….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 today 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).

This time I went for a JavaScript solution from start to end with (nuxt.js), and I’m delighted by all the benefits it brings.

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.

Jekyll, middleman, and Hugo are great tools, but they come with a burden: they are written in a programming language that is not supported by browsers.

Ruby, Go, Python, and all the other languages, are great web-building tools — but they add another layer of complexity for developers. If you want any kind of interaction on your site, there is no way around JavaScript, and every additional language included in the project raises the entry barrier.

Finding good developers is already difficult – finding someone proficient in more than one programming language is even harder.

And I’m not saying that these developers don’t exist; just that having one person being 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.

Enabling the power of isomorphism

In the past, I worked in PHP/JavaScript stacks where I had to write my templates twice – once for the JavaScript jQuery, and another for PHP server-side application.

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; leading 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 advantages of a complete JavaScript stack does not only cover reusing of templates, however.

The principle of running the same code in both browser and server is called Universal JavaScript, and thanks to libraries like React and Vue we are no longer tied to a specific environment. React for example runs in the browser, on servers, on the command line, and probably on platforms I can’t even think of right now. This environment-agnostic approach makes Universal Javascript perfect for static site generation.

You can use the JavaScript application code to generate the HTML and then ship the same codebase to the browser to enable interactivity. This kind of reusability results in a fast initial render time (and we all know web performance matters) without the typical loading spinner of single-page applications; then that evolves to a fully-functional JavaScript app that only needs a bit of JSON to enable further fluent navigations and to stay nicely animated.

Let’s think this through for a moment. When you use a JavaScript application framework to generate your static websites, you’re not building yet another static site – you’re creating apps that can be delivered statically to become dynamic when the client-side JavaScript is executed. This concept is compelling!

A delivery pipeline with excellent developer tooling

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.

How would you handle assets in this setup? How would you minify your JavaScript? Who would optimize your images? Should you use Webpack, Gulp, neither or both? A tool with the purpose to transform markdown to HTML would not be the right tool for the complex Frontend development workflows of today. Of course, you can make it work, but the question remains — should you?

Dependency resolution, code transpilation, file optimization – all these topics are their very own little rabbit hole that you can dive in for days at a time. This research is time well spent, but I’m sure not everybody enjoys the world of configuration and documentation we experience in the JavaScript ecosystem today.

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.

A rich ecosystem with components for everything out-of-the-box

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.

New frameworks specialize in modern Frontend technologies

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!

An API for everything – all you need is only one call away

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.

The struggle of API data in a file-driven world

How do you bring in API data into your static site generator? There are two ways:

1. Someone writes an integration for the tool of your choice
2. 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.

API based static web applications to the rescue

When you’re building static web applications, everything is always only one HTTP call away. Ajax calls are in the nature of JavaScript developers and when you combine these calls with the component driven approach that build Vue and React’s foundations, you end up with a flexible architecture that is ready to scale with your content needs.

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.

GitHub Pages is still an option, even Amazon s3 is great for static site hosting, but new services like Now and Netlify that have entered the scene offer tailored experiences to go static.

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.

Another advantage – all these new tools come with command-line interfaces (CLI’s) available via npm, so you don’t have to leave the JavaScript ecosystem and are even able to troubleshoot problems yourself.

And best of all, these tools come with generous free plans and very little administrative overhead. For me as a JavaScript Frontend Developer, having no devops hassle but being ready to scale is like heaven.

JavaScript is the language of the web, and for me, it feels like we are at a turning point right now – new tools and services are betting on static HTML, enriched with serverless functionality through either Lambda functions or software-as-a-service providers.

JavaScript fatigue (or whatever you want to call the last few years) brought up amazing tools which became a crucial part of our ecosystem, and I tell you... the future is bright!