Database-driven Blogs and static HTML generators


Searching for the right way to set up and maintain this blog and to overcome the restrictions that come with mainstream blogging software and services, I arrived at certain conclusions that you’ll find in the following article. It’s an article about the technical requirements of modern blogging where I consider recent trends and question traditional ways of getting things done. It addresses techies that are about to start blogging seriously, established bloggers and web developers who are looking for state-of-the-art solutions.

Planning the blog

Beginning to plan our next project, we usually choose a familiar tool-set and known services. This way we are able to rapid prototype our application and then concentrate on the actual requirements of the project. But is this always the right path to follow? We can quickly think of how things can be build, we’ve created things that function in the past, we feel comfortable about them and are often allergic to new tools. But this prevents us from perceiving better and smarter ways to fulfill our tasks and we often incorporate unnecessary components into the application. In order to broaden our perspective we need to be aware of the community, get out of our comfort zone of skills and rethink traditions. In the context of project planning, my suggestion is to find the time to experiment and where possible go with open standards. In the coming sections, I have noted some of the things I considered important when planning for this blog.

Gratis hosted platforms

Our favorite free of charge hosted platforms allow us to set up the appearance of our blog in no time and publish our thoughts right away. Popular blogging platforms like, are actually hosting CMSs on their expenses on their servers. But all of this comes with a price. We are restricted to limited configuration choices and third party licenses. We’ll be using themes that everyone else uses, and even when we change the parameters, our blog will have the same look (a nice photo won’t make much difference). Our content will be surrounded by your platform’s banners, icons or logos. Most likely, there will be advertising or links to other sites that we may not want to be displayed on our site. We’ll not have complete ownership of our blog; even if the content we create is protected, the domain will not belong to us. And moving our blog to another host or service demands quite an effort.

Self hosted CMSs

Today, we most commonly choose to install the blogging software (usually a web Content Management System, CMS) on our web servers. Installation is pretty straightforward and it is accompanied by helpful tutorials. The setup of the underlying database may sometimes be tricky for some people, but many hosting providers offer a one-click installation for popular CMSs like Wordpress or Drupal. A self hosted CMS avoids most of the disadvantages of the gratis hosted platforms and allows greater control and flexibility over your blog. And since most of these CMSs are open source, we can install and modify plenty of wonderful themes or useful plug-ins that suit our blog’s needs.

So, in terms of design and layout, we are more autonomous with a self hosted CMS. We’re tied to less company policies and we have more control over the content that we put on our site, no annoying logos, strange links or unwanted advertising. But keep in mind that we need to maintain and upgrade the software ourself and to do this we need to mess with the “backend stuff” (eg. Database). This process can cause a lot of headaches to some folks and it requires particular skills, but we shouldn’t avoid it. Upgrading to the newer CMS version is vital if we don’t want our site to become outdated or run into security risks.

CMSs serve massive and complicated websites, which receive frequent updates by multiple users. For community sites, e-commerce, archives, news portals, wikis, forums, file-sharing sites or galleries, CMSs are the right choice. And that’s because you need a database to store large amounts of content. A CMS, after all, is also a user interface for your database: it offers user-friendly navigation, facilitates the updating and assists the management of the diverse resources you store in your database.

To display the database content on the browser, our site has to be assembled (or generated) each time a client (user) accesses a page. This is a continuous activity that is often characterized as dynamic or, more accurately, database-driven. Database-driven websites need to execute code (most likely PHP and MySQL) on the server in order to communicate with the database and to display the required content back to the client’s (user’s) browser. This process is resource hungry and slows things down (although a good caching setup can speed things up). Unfortunately database-driven websites are also vulnerable to various malicious attacks.

Do you really need a CMS for your blog?

Fortunately not. I found that the database and the accompanied CMS would be unnecessary components in my blog. I thought of my blog (or any other micro-site) as a printed magazine. The printed magazine consists of the front cover, the editorial, the table of contents and the content. Similarly, a simple blog consists of the front page, the list of your posts, the about section and your posts. However, this structure can also be achieved without a database or a CMS and thus without a dynamic setup like the one described above, which bears many disadvantages as to its complexity and performance. A fully functional and easy to manage blog can be built with the use of static HTML generators. A simple static micro site with a news section can also be developed the same way and enjoy all the comforts of pure HTML pages and many more advantages.

When talking about static HTML pages ones mind goes back to the beginning of the Internet where the web was just but plain hyper-connected HTML documents. Back then, the web’s purpose was mainly about retrieving information and not interacting with content. Technological refinement over the last twenty years brought a giant leap in experience and active engagement, especially with the introduction of database-driven websites. However, the effectiveness of good old static web pages, in many areas, remains unbeatable.

Static HTML Generators

Static HTML Generators are simple and brilliant programs. They represent a practical way to create and maintain structured static web sites. They automate many procedures like navigation, design consistency, chronologically ordered list of contents, etc. They output HTML files on the basis of a set of templates where we describe the components and structure of our blog. They keep our content apart from the actual code of the blog, making it much easier to maintain.

Static HTML Generators are not a new idea hitting the blogosphere. Back in the old days, Moveable Type used static HTML output to serve blogs, generating and hosting the pages on its webserver. With the appearance of open source software like Jekyll, Hyde, Pelican and many others (there are really dozens of functional HTML generators out there), the potential of Static HTML Generators has become obvious. These programs run on our local machine giving more control and flexibility over the process of designing, setting up and maintaining our micro-site or blog. They use templating languages to separate (or filter) the content from the layouts and they use simple markup languages like Markdown to reformat our text files.

Edit your new post with your favorite text editor, generate a new output site (single command), check locally, upload to the web. This is the workflow needed to upload a newly created post to your static blog. Static HTML generators are a growing trend among programmers. And for good reason: static HTML generators perform much better than popular CMSs.

The benefits of static websites

A set of static HTML pages performs better for the following reasons:

  • maintenance - A static blog is easier to maintain. Every post is a single file. We can compose or edit our posts in our favorite text editor, using an easy markdown language or writing HTML (and JavaScript if you need to embed various dynamic components into your posts). I dislike WYSIWYG editors because they lack control and implement unnecessary code into the site. The possibility to edit your blog on your local machine and preview articles without any downtime is also a great helper. I don’t have to worry about updating any software or maintaining a database to keep my blog up to date and running.
  • speed - Static pages load relatively faster than database-driven pages. The absence of server-side processes for querying the database makes loading faster. To display a static page, the browser just needs to load an existing HTML file from the server and assemble it on the screen.
  • resources - Static pages are resource-friendly for the web-server as well for the user’s local machine. Minimizing memory and processing resources is always an advantage, especially for mobile devices.
  • mobility - In contrast to database-driven blogs, where our posts are table entries in a database, in a static blog all the posts are single text files, kept in one folder. This is very convenient for migrating or transporting your content to another system or server in the future. This is also very “digital repository” friendly as I mention later on.
  • backup - All the code and content of a static site is kept in one place. We only need to copy-paste or push a folder into our favorite repository and we’re done. All our work is safely kept in our local machine, our web-server or the cloud service of our choice. This is much easier than backing up a database and a (modified) CMS.
  • security - A static configuration is kind of a sealed structure regarding external interventions to our web-server. The absence of dynamic processes makes it very hard or even impossible for malicious attacks, like cross-site scripting, to harm our site.
  • customization - If you are an experienced web developer then you’ll find it more convenient to design and layout your blog using straightforward HTML/CSS/JavaScript code, instead of having to deal with your CMS’s peculiarities.

The digitization perspective:

You might want to consider choosing a static HTML generator only because your content is kept in single files - digital documents, and that’s a big deal if you ask me. Besides the mobility benefits you have (e.g. moving to another server), you can also enhance your articles with your preferred metadata schema and render them fully searchable and interoperable with various digital repositories. The single document possibility for your authored content is similar to the digitization of books or other cultural objects, where raw files are enhanced with metadata to fit chosen standards. It would be something like treating your blog like an ever growing e-book that’s compatible with popular metadata standards. Think of it! Being ready to deliver your marked up content to all kinds of digital repositories (and devices) is a great advantage.


There is always a tradeoff when choosing one path over another. Although you can embed various dynamic components to your static blog via client side scripting, you cannot incorporate more advanced features like role-based access control or a self-hosted commenting system.

If you are planning to create a multi-user site or a blog with multiple authors, a CMS is the only choice for you.

If you really need comments, with a Static HTML Generator you will probably have to use proprietary software. If you don’t mind publicizing proprietary software on your blog, you can easily embed (via JavaScript) a commenting system like Disqus or IntenseDebate; but these services do not save conversations on your own web-server and again they bind you to third party licenses & services. However, if you have the skills to set up a standalone commenting system and you want to embrace foss (free open source software), then consider Juvia, which is a one man’s effort and not a SaaS (Software as a Service), so you need to host it your self.

As for me, for the time being, I consider social media platforms and e-mail a sufficient way to communicate with people who read my posts.


If you care about how to future proof your efforts as a blogger, then it’s worth weighing your options carefully and making sure you protect and deploy your articles on the web in the most convenient way. If you are finally convinced that you do not need a database and a CMS for your blog or any other micro-site project, then choose your static HTML generator with care.

In setting up this blog, my first concern was to overcome the need for a database. Searching for the people that have done this before me, I talked to other programmers, then I read several posts that talked about static site generators. They helped me find the right tool and I started experimenting until I was satisfied with the results. I chose Hyde because it uses the Jinja2 templating language, which is very similar to Django’s and is written in Python. There is a wide selection of static site generators written in many languages. If you have experience with Ruby, then you will probably go with Jekyll.

From the historian’s point of view, the static HTML generators represent a return to the roots, the beginning of the web where everything was just hyper-connected documents. The way I see it, these tools remind us of the forgotten benefits of static HTML pages. They minimize complexity for simple tasks, they can be made compatible with popular repository standards and they are easier to preserve for the long term. It might seem that you are looking backwards - and you are! But you have good reason to do so. You are making certain that your efforts to produce and present all this great content is future proof.