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.
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:
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:
A New Stack
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.
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?
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.