Racket / Pollen First Impressions

Sidebar on Pollen's appeal as a 3rd Way CMS

Right now with CMSs you typically see two approaches:

1. Use a database engine to store, retrieve and manipulate blocks of content and associated metadata
2. Get rid of the database and make the file system do the work of the database.

Option 2 can be faster and simpler to administer, because the queries most commonly needed by a CMS can actually be handled by file systems. Need the ten most recent posts in reverse chronological order? Just store the posts in filenames that use a yyyymmdd prefix. Need categories for your posts? Store all those posts under a folder named categoryname.

But as soon as you need anything more complex than a blog or a simple static site, though, Option 2 gets to be a real pain, because you're trying to get database results without using a database. And this results in even more complexity and friction than you would have by simply using a database.

What if you want a post to appear under more than one category? What if you want a keyword-based index? How about a comment system that where you actually possess the comments yourself instead of using Disqus? How about including new comments along with posts in chronological order? If your CMS depends on the filesystem to handle all its queries then you're looking at a lot of hacks to get what you want.

(Faced with the limitations of the database-less CMS, the common response is Yay Simplicity We Don't Need That Anyway. "Disable" comments. Get rid of categories. Get rid of search. Obviously this is a valid approach. But the ability to add, display, and link the same content in multiple organizational contexts is one of the core benefits of the web as a medium. There are experiences I want to offer readers that depend on this. Cutting yourself out of those possibilities in the name of simplicity seems kind of sad to me.)

So what's the 3rd way? It's treating the site (or the book, or whatever) as a program.

• You stop relying on formatting languages like Markdown and YAML for formatting and metadata: these are defined and implemented by other people, so you're always at their mercy when trying to manipulate your content
• You stop relying on the file system for any metadata. The file system still houses your content, sure, but you don't depend on paths and file names to store information needed to select and organize it.
• Your content is code (or structured data, depending on how you look at it). Each page of your site, being a program, loads and runs this code differently depending on the context.