The Return of the Static Site
It’s true that our web team spends a lot of time making web apps, but building beautiful websites also falls under our domain. And lately, there’s been a website trend that has been popping up all over the place — static site generation.
People like me, those with some gray in their hair, will spot this as a rehash of a previous strategy, but this time, thankfully, the technology is finally ready to properly support it.
History
Back in the early days of the web, just about all sites were static. The result of “making a website” was some HTML/Images (and CSS, once that came around) that could be put on any web host. It looked roughly like this:
Back then, when we wanted to do more with a site (templating, form submission, changing data, and admin), we needed a system that ran scripts on the back-end. CGI with Perl was the first interface there, but it soon evolved and improved from that. We developed stacks of technologies, one of the most popular being the LAMP (Linux, Apache, MySQL, PHP) stack. This allowed for database-driven websites whose content rendered from data in the database when requested. A large percentage of websites out there today are based on the LAMP stack based Wordpress, which was an early database-driven platform for content on the web.
It looks roughly like this:
Note: Mobelux is not a PHP shop, the LAMP stack is being used as a reference because of its popularity. Our backend code is mostly written in Python, Ruby, or Javascript.
The Problem
The issue with these database-driven sites (like those built on Wordpress) is that the extra moving parts can each individually break and kill your entire website.
While Wordpress has dramatically improved its security, you used to have to update your install every month or you would get hacked. You would then have to call people like me, who would have to spend way too much time fixing it.
Those are the dark days we try to forget.
Additionally, if you were lucky enough to get a post or page shared on a popular site that would get you a lot of hits, your web server (running PHP) and/or your database would completely fall over. A lot of work went into being able to scale this type of platform: caching, CDNs, auto-scaling servers, etc. A bigger install ends up looking like the following, with each piece being able to scale up:
The Evolution
I’ll take a slight detour in our story here to talk about how the web has evolved over the years. HTML was made as a content presentation platform, and while early JavaScript allowed some interactivity, it took a while to really evolve. The big web players were pushing it to be much more.
HTML5/JavaScript is now approaching a real application platform that’s been taking cues from other application platforms like Windows, iOS, Android, etc. On those platforms, if you needed to send data to a server or get some dynamic data, you communicated with an API. If that API was down, these dynamic pieces wouldn’t work, but the rest of your app should still function just fine. This has enabled sites like Facebook to be incredibly complex applications, and it has pushed the technology to a place where we can rethink our stack.
A New Stack
This evolution has led to a new, more modern stack, called JAMStack, i.e. Javascript, APIs, and Markup. The general change in patterns means that what you end up with is much more similar to a combination of the early website pattern and an application pattern.
The Benefits of JAMStack
A JAMStack site builds on a lot of pieces developed along the way, loosely coupling these pieces to allow superior reliability. It takes advantage of CDNs to offer a much more robust caching solution than other stacks. Plus, there’s no server site rendering blocking initial load, so the speed you get is a big improvement.
Extra Pieces
There’s an ecosystem emerging around technologies to support JAMStack sites, such as static site generators, headless CMSes, and serverless APIs. These are loosely coupled as well, so that they don’t break everything if they happen to go down.
- Static Site Generators (SSG)
These allow templating, making pages from data, and other niceties that we’re now used to.
If you need an admin interface for your content, you can still have it. Content is simply now separated from presentation. You administer your content, and your SSG builds the presentation from that content.
- Serverless APIs
Until recently, if you wanted dynamic interaction with an API, you still needed a server running that API. This kept us from really gaining all the benefits of using CDNs — mainly, having no servers to manage. That changed with the addition of serverless/function based offerings. AWS Lambda, Azure Functions, and Google Functions now all support this type of offering, allowing you to pay per execution of your API instead of paying to run the server. It also allows for huge API scalability.
And now, some good links
Smashing Magazine was one of the first larger content sites to roll out a static site. Notice how ridiculously fast the site loads.
Hosting company Netlify was built around the idea of static sites.
Why Static Site Generators Are The Next Big Thing. A post on Smashing Mag by the CEO of Netlify goes into more detail.
What’s our team doing?
The Web team at Mobelux is a React (front-end) and Python/Ruby (back-end) shop, often focused on web apps, so initially it seemed like we could end up in the difficult situation of having to work in different technologies when we were building apps vs. sites. Thankfully, Gatsby is a wonderful static site generator based on React as its Markup (the M in JAM) as well as its JavaScript, and it recently went to 1.0+. Gatsby has let us build static websites in the same technology stack that we use to build web apps.
We were already all in on GraphQL for APIs (which I spoke about at RevolutionConf this year), so using that as our data language in Gatsby fit very nicely with our workflow. We can still write our APIs using Python or Ruby as well, keeping those skills relevant.
Our own proprietary CMS (still in the works) was turned into a headless CMS (with GraphQL API), but more on that soon. For some of these sites, we’ve been using the aforementioned Netlify, and the workflow integration with Github is wonderful.
Taking advantage of those pieces allows us to build fast, reliable, scalable sites using the technology we prefer — and as a bonus, weekends are a lot more carefree, knowing an entire site won’t go down without us. If the return of static sites is the way of the future (even if it was also the way of the past), we’re definitely on board.
