I'd like to say that it's been a long, hard road to finally get the layout and functionality of my blog site updated, but it actually hasn't.
If you've been here before, and you're here now, you've undoubtedly noticed that this site is now completely different than how it used to look and function. Finally, I have busted away from the shackles of minimalist, or brutalist, layout and design that I created in 2015. Finally, I have created a new, decent layout that is something more than the barren layout of yesterday. A lot has changed since 2015. Both in my personal life, professional life, and honestly, the entire outer-world.
However, the biggest change was not with the layout of this site, but with what's powering this site. Previously, I used Pelican, a Python-based static blog generator, to build my site, and then upload the changes to my webhost. Pelican worked by taking a directory of markdown files and transforming them into HTML markup, and then slipping that into a bare/basic page template I made. This worked well, outside of remembering the commands to get Pelican to regenerate the the site every few, sparing months I had something to write/post about. But it was always a little bit of a pain. Launching Terminal.app. $ cd'ing to the right directory. Activating the virtual environment...
I'd actually thought about giving the whole setup up, and returning as others have to something like wordpress or a traditional CMS.
The downside is... well, security and keeping everything updated. And the mess of dealing with a RDBMS on the server, keeping that secure and updated. I was baseline-tepid about the prospects of that.
A few weeks ago, I discovered the concept of the flat-file CMS while browsing around developer/tech sites. People posted about three strong flat-file CMS contenders.
All three of them look great. And the thinking behind them is genius. With more functionality than a command-line static blog generator (like Pelican) or a crazy-heavy RDBMS CMS (like wordpress), these flat-file CMSes fall somewhere in between. The store their data in a series of files in a directory structure on the file system, and then magically pull it all to life, doing the transforms from markdown to (HTML) markup on page-load (with caching, to be sure). But they also include, in some cases, really slick admin interfaces.
The first of these CMSes that I looked into was Kirby. Their admin interface looks great and polished, the featureset looks strong and honestly, it just has a really positive vibe about it. It does cost for a license, which, to me is not a mark against it, as it might be to others. I have no problem paying people for their hardwork in creating polished and well-built pieces of software or software solutions.
Next, I looked at Grav. As you might guess from the title of this post, this is the flat-file CMS I chose to use to rebuild this website. Like Kirby, Grav is polished and has a great feature-set. Grav, from my initial impressions, also looked to be a bit more powerful and developable than Kirby is. The futher I looked into Grav, the more enamored I became. Not only did it have a great admin interface, it also came with, or had available, a handful of incredibly useful plugins.
The Pros of Going Grav:
The Cons of Going Grav:
In general, I LOVE Grav. Seriously, kudo's to the Grav team. I can't tell them how much I love what they have created and how nice and refreshing it has been to use (especially after wordpress monoculture took over the world).
I also considered Lektor, which looks like another great option from what I saw. The bad thing is that I become so attached to Grav that I haven't yet given it a spin and don't really have any sort of analysis on it yet (maybe in a future post).
Grav is a CMS that I truly feel as though I can build great sites with. It makes great choices, it gets out of your way, and yet it's still remarkably powerful in what it lets you do. For any of you out there reading this post, Grav is great and I highly recommend downloading it and putting together a demo site.