My first experience with a dynamic website was in high school.
I was in a Venturing Crew,[ref]A co-ed, outdoors-focused organization that’s part of the Boy Scouts[/ref] and my friend Taylor had helped us put our group online with a website hosted by another friend. This website was built in classic ASP and used a Microsoft Access database on the back-end to house content.
I hated it.
The website looked great to visitors, but was messy to manage. I never once managed to post any new content of my own and would usually give up after a few hours of head scratching and just email my content to the team instead. Eventually my meeting notes would make it online, but I think only once it was by my own doing.
I swore off websites, databases, and web development entirely before graduation.
Round Two
Around the same time WordPress was just becoming a thing, I took a second crack at having a website. My college gave me a URL and hosting for free, so I figured it was only prudent to leverage these resources while I was still a student.
My options at the time were:
- Resurrect the ASP-Access monstrosity we’d used in high school (Nope)
- Learn enough about Linux to install one of the available open source packages available (Considered b2. Decided it was too much work)
- Build a static HTML site and forego any sort of database administration (Winner!)
I liked the idea of static content because it was straight-forward, freed up my time to do something that didn’t include studying Linux man pages, and leveraged the pirated copy of FrontPage I’d gotten from a friend. It felt like a win-win-win for me.
Managing a site built in static HTML is a major pain.
I blogged a few times each week for over a year, and eventually abandoned my site because manually manipulating HTML for every post was time consuming and mind-numbing. As much as I missed the WYSIWYG built in to the ASP-Access solution, I wasn’t ready to go back to a convoluted database setup.
My junior year I abandoned my self-hosted site for Blogger.
WordPress
Grad school introduced me to WordPress. I finally buckled down and learned PHP – not because I wanted to, but because I’d convinced a client I knew it and wanted to actually get paid for some freelance work.
Eventually I learned enough about the platform, server administration, and database configuration to be considered somewhat of an expert. I speak frequently on the platform and have maintained a WordPress-powered blog for seven years this month.
That said, I’m still fairly critical of the system. I know where it’s come from, I know where it is today, and I have a good idea where it’s going. I also have several thoughts on where I’d like to see it go.
One of those thoughts is around data portability – I absolutely despise the current MySQL setup. It’s just barely scalable and is incredibly difficult to move from one location to another. I would love if I could keep my post content version controlled, perhaps through a system like Git, making it easy to move without sacrificing the ease of presentation.
Jekyll
Based on this desire for versioned content and simple portability, a few people suggested I look into Jekyll. The promise was, once I used Jekyll I’d leave WordPress and never look back.
Wishful thinking on their part.
What I do like about Jekyll is that all content and site material (i.e. theme) are housed in the same repository. Thanks to Git, you could easily maintain multiple versions of your site – to test a theme, to test different structures, etc. Switching between one or another would be as easy as [cci]git checkout other-version[/cci].
What I don’t like about Jekyll is the very developer-focused environment.
There is no WYSIWYG interface – all content is written in markdown, which isn’t too bad from a developer perspective, but which makes visualizing your content incredibly difficult.[ref]This is also the reason I don’t consider Ghost to be a WordPress killer. Yes, markdown is simple to use for developers, but if you’re trying to write and layout a specific article its an unnecessary pain in the ass.[/ref]
The setup is also incredibly convoluted. I made my first attempt with a GitHub Pages setup. In order to make things work (i.e. preview the site to make sure it worked before I pushed things live) I had to install Jekyll itself on my local machine.[ref]I already have Ruby and Bundler installed for some other development work. Frankly, though, needing to install developer tools to preview a blog is asinine.[/ref] Once I did have things set up, previewing the site worked well, but it took a while to figure out why, even though I’d added content to the [cci]_posts[/cci] directory, content wouldn’t show up.
In all, it took me almost two hours just to get “Hello World!” printed on my new Jekyll site. This could just be inexperience with the platform; it could also be that there are no user-friendly guides to setting things up.[ref]Yes, there is loads of documentation. But they’re all written for developers with experience in Ruby, Liquid, and Jekyll itself. If you’ve never worked with any of these before, good luck trying to figure it out.[/ref] For context, my parents use WordPress. My dad’s still using the same cell phone we got him in 2002 – and even he was able to set up a new WordPress site in less than 10 minutes.
I complained about Jekyll on Twitter shortly after I lost a good chunk of my day trying to figure it out. The first response I got was fairly telling:
https://twitter.com/bastosmichael/status/487780343861088256
The thing is, I was experimenting with Jekyll to build a documentation site. Like a blog, it would involve a considerable amount of writing. Unlike WordPress, it would involve several writers collaborating on the same document, often at the same time (a task for which I felt a Git-based CMS would be well-suited). The act of writing (producing raw, unformatted content) will be fast – it’s just another document. The act of setting up the tool, however, was incredibly painful and absolutely not easier than WordPress.
Trying to produce well-structured, visually attractive articles on a tool that’s difficult to set up, however, is a non-starter. Even once I get things set up on my machine and hosted, training new writers (and getting things set up on their machine for previewing content) has limited return on what will be a significant investment.
WordPress has a long way to go to becoming what I would consider a perfect platform. Jekyll has even farther to go to even catch up with WordPress in the first place.