Photo Credit: Micolo J | |
Update
Just 9 days after writing this article, Parse announced they’re shutting down. Parse is a cloud database (with many other back-end services) that many have built their mobile and web applications on top of (myself included). Just like that, in one swoop, many applications will die a swift death unless significant effort is put in to move them to another service. This further reinforces my point about the mortal web. You cant just build something and expect it to live any reasonable amount of time without continual maintenance.
I’ve been building websites for the last 15 years or so, and during that time I’ve seen the rise and fall of many web technologies.
One of the most depressing thoughts I have about web development is that the average lifespan of a website or web app is about 5-10 years.
You can take the same size workforce that built many of Europe’s still-standing thousand-year-old buildings, put them to work on building an enterprise web app, and in about the same amount of time it would take them to build one of those timeless buildings, you’d have an app that would stand for 5 years if continually maintained.
The story of coryshaw.com
About 10 years ago I got ahold of this domain (coryshaw.com), installed WordPress on my shared hosting, and wrote a few articles. That timeless content I wrote ended up living for a couple of years. It was barely a toddler! Life got busy and I didn’t take the time to update WordPress. As a result, my database got hacked into by a bot and injected with hundreds of pages of spam.
Feeling overwhelmed with the task of cleaning out the spam and de-hacking my site, I declared website bankruptcy and started over with a clean database and WordPress installation. I then wrote a few more heart-felt timeless posts of wisdom, and once again got busy with life and work.
Fast forward another few years, and the site once again got hacked into (you have to be quick on that WordPress update trigger). This time I spent a few hours cleaning it out, but it was a major hassle.
Fast forward another few years, and for no good reason every page of my site was replaced with some obscure php error message: “Warning: Cannot modify header information - headers already sent”. I literally fixed it by pulling up a config file and re-saving it on my server. Huh?
All of these things happened without me lifting a finger…probably as a result of me not lifting a finger to continually maintain the software that serves my content.
This is just one story that sings to the same tune as many other of the side projects I’ve built over the years.
When I write or build something, I want it to live forever without having to continually maintain something else. Like an eternal paperback book.
Creating an eternal website
One way to almost guarantee an eternal website is to make it 100% static with as few dependencies as possible. No Database, no Node, no PHP, no Rails, no back end, no nothing. Just basic html, some CSS, maybe a little JavaScript sprinkled in, and content.
Building a static website used to be a really tedious task where every HTML file would have the same header/footer code, and updating things later was a messy task of find and replace. Eventually back-end technologies arose to solve many of these problems, but at the expense of adding dependencies into the stack, and mortalizing your site.
Enter Static Website Generators
Thanks to some modern frameworks like Jeckyl, Hugo, and many others, you can now have the best of both worlds. Static site generators give you all the fancy tools provided by your average back end technology: DRY development, partials, layouts, themes, and most importantly, content that is completely isolated from the rest of that other stuff. They generate your entire site as static HTML files on your local machine, ready to send to your web host of choice, where they can live eternally without (hopefully) a single external dependency.
In 5 years, when that static site generator you used stops working, no big deal, just find the next best thing and spend a few minutes re-jiggering your partials and layouts into whatever the new thing is, feed it your content, and keep going.
The new eternal coryshaw.com
By now you may have guessed that this article was written and published using a static site generator. Go ahead and bookmark it, then set a reminder 10 years from now to click that link. Chances are it’s still here, where it will always be.
To build this site at the time of this writing, I used Hugo. It’s built on top of Google’s Golang which makes it lightning fast for generating your site.
Rather than adopting one of the other themes you can use with it, I decided to dive in and build my own from the ground up, and open sourced it to share with the Hugo community.
Where static sites wont work so great
Static sites obviously aren’t for the entire internet. Some apps will always need a back-end. Is an app even an app without a back end?
Nowadays it’s not uncommon to have a completely static front-end powered by a back-end hosted on other servers in the cloud. You just have to watch out for that pesky Same-Origin-Policy when making api requests from the client. Luckily, there’s a solution to that with Cross-Origin Resource Sharing (CORS).
Unless you’re running the NY Times and have lots of people generating and updating content on your site many times per day, there’s very little downside to using a static site generator for a blog or content site.
Static Applications
It doesn’t just stop at content sites.
If you want to build a static application, there are lots of options. Need a database? Use Parse or Firebase. Need a commenting system? Embed one using Disqus or Discourse. Need to hit an api? Make it a service on a different machine and keep it separate from your front-end.
It can be really liberating think of your application in terms of separate services, and running a static site forces you to think this way.
Raw Unadulterated Performance
My favorite side effect of static sites is great performance. Without a back-end or any external dependencies to wait for, static sites load nearly instantly. What’s even better is that you can serve your site entirely from a CDN.
I’m still in the honeymoon phase of it, but I think static sites have a bright eternal future in this chaos that we call web development.
Hey, thanks for stopping by! We should stay connected. If you'd like to reach out, you can connect with me on Twitter, YouTube, LinkedIn, Facebook, or Soundcloud.
Also, you can check out some other stuff I've done for clients over at User Kind, Inc..