Introducing DatoCMS: a CMS for static websites

A headless CMS combined with static site generation brings together the advantages of a traditional CMS and those of a high-performance static site. In practice, it lets you manage content comfortably while delivering an ultra-fast site to your visitors.

First of all, what's the difference between a static site and a dynamic one? To an outside observer, none: both look exactly the same. What changes is how the HTML pages that make up the site are written.

A static site is made of a set of HTML files organized in different subfolders. No PHP, no Ruby, no database, no CMS. Just plain, old, boring text files that are uploaded to a hosting space when published, and from then on can be viewed as they are by any visitor.

A dynamic site, on the other hand, is a site whose HTML pages are "written" on demand every time someone visits it. Written by whom? By software that lives on the hosting space and constantly listens for new requests to fulfill.

A website that needs to show different information depending on who is browsing it has no other way to go, and that's exactly why, right now, almost every site we browse every day follows this very logic.

This drastic shift from static to dynamic was the lever behind the digital revolution we're living through this decade, but it certainly didn't come without drawbacks or costs:

1. Hosting and performance. A static site can be hosted very easily on a CDN, a network of servers evenly distributed around the globe. A CDN guarantees extremely fast response times without outages: if one of the servers in the network goes down, traffic is simply redirected to another one. If I have a WordPress site hosted on Aruba and the Aruba server catches fire, my site stays offline (any reference to actual events or persons is purely coincidental).
2. Security. A static site has no "moving parts", so it is physically impossible for it to be hit by attacks of any kind. Period. Once online, a static site stays online forever.
3. Speed and simplicity. Since it is prebuilt upfront, a static site needs no engineering effort to optimize page rendering times. On top of that, the need for ongoing maintenance disappears completely: there are no servers or software to update, because they aren't part of the architecture.
4. Costs. Scaling, meaning keeping the site running properly as the number of visitors grows, is much, much, much cheaper with a static site. There's no need to buy bigger hosting plans or deal with uncontrolled traffic spikes: the CDN handles everything automatically.

Let's pick up where we left off: almost every site we browse every day is dynamic. In light of these undeniable facts, the obvious question is: haven't we gotten a little carried away with dynamic sites? :)

Leave aside Facebook, Twitter, Google and the other web giants for a moment, and focus on the remaining 98% of the Web: how many of these sites actually show different information depending on the visitor, or get updated in real time? And how many, to push it, are updated no more than once a day?

For all these sites, the "dynamic" part of the architecture is really only used by admins while browsing their CMS backend to update their site.

The rest of the time, tens of millions of servers around the world keep producing, on every visit, the very same page they produced a second earlier, and visitors "suffer" a dynamic architecture that only hurts their experience: slowness, instability, potential vulnerabilities.

It's important to realize that, for the vast majority of websites, a "dynamic" architecture is nothing but a huge, unjustified cost: what the average site needs as a standard is a "semi-static" architecture that combines the best of both worlds.

1. offer a CMS that lets anyone update their own site independently, without any advanced technical skills;
2. whenever an admin changes the site's content, automatically generate the new static HTML pages once, and serve them via CDN until the next change.

Fortunately, the last point is a problem already solved by tools called static site generators, which do exactly what the name says. There are hundreds of them, for every taste and in every possible programming language. The problem is that today they are aimed at a niche audience, mostly developers. You need to know how to run terminal commands, handle Markdown files, edit configuration files... nothing complex, but simply out of the question for a non-technical audience rightly used to the simplicity and immediacy of a web-based CMS.

We imagined a service that could solve all these problems, and we built it with a true MVP mindset: the bare minimum needed to validate the core idea.

Let's say we want to use DatoCMS for an events website. DatoCMS can generate what we've called Spaces: full-fledged admin backends to manage content of any kind and shape.

The first step is to point a second-level domain of our choice to a specific Space through a CNAME entry. From there, we can add an unlimited number of editors to our Space, who can log in and manage the site on their own.

Logging in to the DATO admin

Once logged in, this is what you see:

The DATO admin home page

Sponsors, Talks, Posts, service pages... in just a few minutes, developers can tailor the editing experience to the site's specific needs, setting up custom Content Types with exactly the fields required.

Today DatoCMS offers the following field types (optionally multilingual):

• Text (Title with slug, String, Textarea, WYSIWYG)
• Numbers (integer, float)
• Booleans (checkbox)
• Date/time
• Images (drag & drop with AJAX upload to Amazon S3 and image processing via Imgix)
• SEO information (meta title, description, Twitter Card, Facebook Open Graph fields, ...)
• Relationships between records (one-to-many, many-to-many)
• Geographic coordinates via Google Maps

New fields will of course arrive as soon as we need them. Content Types can generate collections of Records (e.g. blog posts) or be "singletons", allowing a single Record to be edited (e.g. Homepage settings).

A model form with the fields exposed by the API

DatoCMS exposes an API that any static site generator can use to fetch all the data stored in the backend. A first plugin has been built for Middleman, letting you work with DatoCMS just like its local Data files. There are also helpers that automatically generate the SEO information for each page.

DatoCMS works hand in hand with a Continuous Deployment system (so far an adapter has been built for GitlabCI): as soon as an editor changes the data, DatoCMS lets the user know the changes need to be published and can trigger, via webhook, a new static build and publication of the site on Amazon S3 within seconds:

When any user edits content, an alert appears.

The publishing step generates the static content and publishes it to the CDN in about 30 seconds.

The site is live, yeah!