Ten Myths about Static Websites

If you’ve ever searched out the differences between static websites and dynamic websites, you’re likely to have discovered several questionable — if not outright false — statements about what static websites are and aren’t capable of.

Whether these myths came about from misunderstanding or misinterpretation, let’s set the record straight, shall we?

Myth #1: Static sites are difficult to edit.

This myth is probably the most common one I came across. I’m guessing it comes either from someone looking at a raw Markdown file, not realizing how simple it can be to edit, or the received wisdom that static site pages have to be edited one by one (see Myth #2 below).

The fact is, there are dozens of static-capable content management systems (CMSs) that make editing static websites as easy as working in a rich text editor. Some, like CloudCannon, even add advanced visual page-building into the mix, so anyone can edit and create static pages, as well as manage the contents of their own website.

​​​​​Myth #2: You have to edit each static page separately.

Ok, this one’s false, but the misperception is grounded in history. In the 1990s you would have had to duplicate a layout, navigation, or footer across every single one of your site’s pages.

These days, however — and by that I encompass the last twenty years or so — tools called static site generators (SSGs) use templates to build all of a website’s pages. You can design a layout once, and it’s applied to as many pages as you want.

Myth #3: There’s no JavaScript in static sites.

I’m honestly not sure where this one comes from, or the complicated chain of hearsay that must have given it life.

Some SSGs do not use JavaScript when they build websites; others do, but try to minimize the amount of JavaScript that loads in the client’s browser. What all SSGs share, however, is the capacity to use JavaScript within a webpage if a developer wants to use it.

Myth #4: Static sites can’t use external data or APIs

Static sites commonly use external data stores such as JSON, CSV, XML, YML and TOML. They also use APIs for additional functions such as analytics, commenting, search, and ecommerce.

Myth #5: Static means I can’t use videos or animations.

This one’s probably based on a literal interpretation of the word ‘static’, meaning unmoving. Let the record show that a static site is static in its delivery method only — the site is built by the SSG, and is then immediately ready for user browsers to load, complete with the full spectrum of CSS animations, and as many embedded videos, and GIFs of cats playing keytars as you’d like.

Myth #6: Static is only good for tiny sites.

Not at all. This could be related to Myth #2, but I’m guessing this one is connected to the ‘build time’, which is how long the SSG takes to construct HTML pages. The truth is, SSGs like Hugo and Eleventy are incredibly fast at building even large sites. A CMS like CloudCannon — the content management layer that acts as a bridge between the user and the more technical SSG — also helps to reduce build time for non-technical users, who are able to edit as they please and build their sites when they choose to do so.

Myth #7: Static websites are usually created in simple text editors like Notepad.

Not as a matter of course. (Unless you really love Notepad.)

Static sites are usually created in two main ways, depending on who’s making them. Non-technical editors (like marketers or copywriters) can create new static sites from a template, and edit them in the browser via a user-friendly CMS. Developers will usually use CLI tools to create their sites locally, and then connect those files to a hosting service (and likely a visual CMS, when they hand off the new site to their content or marketing teams for their ongoing use).

Myth #8: The static approach for websites is “old-fashioned” or “simple”.

Again, this misconception is rooted in web history (static delivery is how the web used to work), and carries with it an unnecessary negative connotation. Static delivery is simple, in the sense that it requires fewer additional services, less computation, less energy, and all else being equal, the webpages load faster. If that’s “old-fashioned”, then color me old-fashioned. What this approach is not, however, is obsolete. In fact, I’d go so far as to suggest that static sites — which have a much smaller stack of interdependent systems than their dynamic equivalents — will have an easier path to adapt to future shifts in web infrastructure.

To be clear, there will always be a use case for both static and dynamic sites. But what people seem to be suggesting with this kind of comment is that web developers should always use the latest and shiniest tools because they’re newer. And that’s great, but only if the site needs them! The truth is, many websites would be better served (faster, more secure) with a static approach.

Myth #9: Static sites “don’t respond to user actions”.

This myth is a little vague, to be fair, but is the only one that has a kernel of truth. Static sites respond very well to user actions — the pages load incredibly quickly, and together with APIs and JavaScript, offer an excellent user experience for a wide range of use cases.

What static sites don’t do, however, is show different content to different users, based on their viewing habits or a user's past actions on the site.

Myth #10: “It can be hard to scale a static website to add new content, once you’ve built the basic structure.”

As far as scaling your website for massively increased user demand, that’s more to do with how you host your site, rather than a question of ‘static versus dynamic’. Whichever approach you take, you can choose from a wide range of hosts and content delivery networks.

In terms of scaling up a static site with new content, this myth couldn’t be further from the truth — as though (and feel free to imagine my best Don LaFontaine impression here) we lived in a world without content management systems. CMSs solved the problem or adding, editing, and managing pages, assets, and site content many years ago, and we’ve been improving on these processes for a long time.

Most web developers will know that building out the structure and scoping the functionality of a website can be a significant task. Once that’s done, however, adding new content to a static site is as easy as clicking a button within a CMS.

As I’ve mentioned above, CloudCannon exists to make it easier for everyone to create and edit content on static sites. We’ve built our CMS around eliminating or minimizing the real or perceived drawbacks of static sites, all the while augmenting the many benefits of static delivery.

There we have it.

Well, that's it. The most common myths about static websites I could find, all put to rest with a minimum of fuss and bother. If you’ve heard any other tall tales about static, I’d love to hear them — let me know!