These days, dynamic websites are well within the reach of every web designer. We often don’t think twice about using tools such as WordPress or Drupal to power our next great project. Their functionality and flexibility make producing data-driven websites easier than ever before. But it wasn’t always this way.
The web started out as a mostly static affair. Plain old HTML was, and still is, the basis of a site. But back in the day, the ability to dynamically generate content wasn’t widely available to the average designer.
Too Much Static
When my career got started in 1990s, every site I built was static. Granted, I didn’t know a whole lot at the time. Thus, so many of my projects became unwieldy nightmares when it came to maintenance. The task of, say, adding a new item to a navigation bar meant hacking my way through potentially hundreds of HTML files – depending on the size of the website.
As time went on, some conveniences such as server side includes (SSI) made maintenance easier. Instead of changing multiple files to reflect a new navigation item, it was now a matter of editing just one or two. Still, tasks like maintaining a site’s SEO remained painfully manual.
So, when the use of content management systems (CMS) became prevalent, I happily hopped on board – and never wanted to look back. For years, I’ve dismissed static HTML as outdated and no longer useful in most situations.
Lately I’m beginning to think that my dismissal may have been a bit unfair. Sure, those old school sites I worked on were a cause of major frustration when changes needed to be made. But does that mean static HTML no longer has a place on the web?
HTML: Abused and Misused
Part of the problem with using static HTML, for me at least, was the fact that it was forced into duties it should have never had in the first place. The intended use for HTML was as a markup language – not as a means to manage complex arrangements of files. But for websites built on a small budget, it was pretty much the best tool we had at the time.
As you might recall, we used to use HTML for all sorts of things that it wasn’t intended to do. Remember using nested tables to hack your way through a page layout? Through no fault of its own, HTML became a whipping boy for how not to do things.
Even today, I still manage a few really old sites that were built this way. And each time I have to make a change, I’m reminded of the mess I made. It’s no secret that something like WordPress is far better for managing content, just like CSS is far better for creating layouts.
However, I now realize that static HTML sites can still have a place on the web – provided we use it in the right way and under the right circumstances.
Two Ways to Build
Editor’s Note: As a few commenters pointed out, I missed something rather large: Static site generators. This was something I hadn’t even thought about while writing this post. My initial aim was more in the realm of the “traditional” static site. With that in mind, this section has been added for a more accurate representation.
Traditionally, static sites were built with the help of a WYSIWYG editor or even by hand. This can still work just fine for smaller projects but isn’t ideal when your needs are more complex.
Once you’ve configured your site through the use of HTML templates and content consisting text files, a static HTML site is generated and ready for uploading to a server. For a more in-depth overview of how these tools work, check out this writeup from Eduardo Bouças.
Where Static Makes Sense
In modern times, just what is the right circumstance to go with static HTML? I think it largely depends on both the needs of your project and your skills as a developer. But, generally speaking, these might be some instances where it makes sense:
Full-On CMS Functionality Isn’t Needed
As mentioned above, a static site generator can provide some of the benefits of a CMS – but not all. So news-oriented sites or blogs that depend on a constant stream of updates may not be the best candidates. Still, that leaves an awful lot of websites that could conceivably benefit from a static build. Standard “brochure” style sites, for example, could be a perfect fit.
Your Clients Don’t Need a Back End UI
One of the best parts of a CMS is a user-friendly back end where just about anyone with a little training can make updates. But not everyone requires this kind of setup. In those cases, static HTML can do the job.
You Don’t Want to Deal with Software Updates
One of the most compelling arguments for static HTML may be security. If you don’t bother to login to a CMS for six months, your site could be wrought with unpatched security holes. While things could still go wrong with a static site, a compromised plugin or database are two less things to worry about.
Budgets Are Tight
Getting a fully custom WordPress site (one with an original theme) can be out of the price range for some smaller clients. In those cases, a simple static site can cut costs, perform quite well on shared hosting and still look every bit as professional.
There’s Still Room for Static Websites
I fully believe that the rise of the CMS has brought the power of the web to the masses. It means that just about anyone can run their own online store or publish their thoughts from anywhere. But, there are still situations where a static website may well be the best option.
Now that we’re surrounded by this data-driven technology, it’s easier to see the contrast of what static HTML has to offer. We know both its strengths and limitations. And we have a clearer understanding of how it’s best implemented.
So, I must apologize. Static HTML, you’ve still got it.