• Database
• Static Files
• Creating Content

Static files vs database-backed blogging systems

• March 2007 - Brent Simmons - Imagining a Node Blogging System for Geeks
• March 2011 - Brent Simmons - A plea for baked weblogs
• July 2002 - Aaron Swartz - Bake, Don’t Fry

When I started blogging in the summer of 2001, I used a Perl app called Greymatter that allowed for content management through the browser, but the app created static files. Not database. It was simple but effective. I enjoyed using it. I also deployed it at work as my personal knowledge management system.

I created the first Mud Hen Hash House Harriers website with Greymatter. Here's a view of the site from November 2002 at archive.org.

Database

I prefer the database because it's easy to write, read, and search. The database is good for frequent posting like I do, especially with the "notes" or microblog posts.

And I want the wiki-like features, such as double-bracket case to create links to articles, versioning, differences, redirects, and template includes even if I don't use these features every day.

I guess Junco-powered JotHut.com is less of a blogging system and more of a publishing app. It's my personal content management or knowledge management system that is used to store many types of text content, such as ideas, opinions, notes, and recipes.

And I want to be able to create and edit notes and articles from not only my laptop but also from a tablet, dumbphone, and smartphone.

I'm not concerned with traffic. I want a place that easily stores and retrieves information that interests me.

It would be nice to backup the markup text and the date stamp for every post somewhere. I create a MySQL database dump file every night. I could copy this file or reload the file on a new server. That would be option one, assuming that I have this file.

But if the whole server flamed out, and the hosting provider did not have the backups, then I'm toast. I occasionally, like once a week, download the most recent database dump file to my laptop.

It would be nice to store markup content at a place like Dropbox for backup purposes. This process would run nightly. All the notes or microblog posts would be gathered in one file. And then all newly created or updated articles or blog posts would be dumped into their own individual files. I don't need every version, just the most recent one. Then these postings would be pushed to Dropbox. I would include meta data with each posting, such as the date-time stamp and the content ID number.

As long as I have the markup saved, then I can get it reloaded into a database and organized within my Junco code.

In 2013, I migrated all my microblog posts from ToledoTalk.com to JotHut.com. I preserved the date stamps. I still need to migrate thousands of thread posts, articles, and comments from Toledo Talk to JotHut. Unfortunately, I don't save the Textile markup for comments at the Parula version of Toledo Talk. I did not use any type of markup text for the first version of Toledo Talk.

Static Files

For infrequent blogging or publishing, like once a day or only a few times a week or month, then I could see the acceptance of a static site generator.

This type of app may only work well when using a desktop/laptop. For a static site blogging app, can a user create or edit posts on a phone or tablet?

With static systems, it would be easy to migrate the content to another server. I assume the markup would be copied. Maybe the HTML too, but as long as the markup and maybe a date stamp for each post has been preserved, then it should be simple to recreate the site.

It seems that static site apps require too many steps to publish an article.

Creating Content

To publish a microblog or note at JotHut, which uses my Junco code:

1. enter text into small textarea box on the homepage
2. click the post button

To publish a blog or article at JotHut:

1. click the hamburger icon
2. click the post link
3. enter text into textarea box
4. click the post button

It would be three steps to create a blog post if I left the post link in the nav bar across the top of the site, instead of burying nav bar options within the slide-in menu. I wanted to simplify the look and remove links. That meant one additional click or tap by hitting the hamburger icon.

If I want to create or edit an article with the advanced writing area, then I need to add one additional step: click the split link.

#blogging - #design - #programming - #blog_jr