So here are… I’ve redone my blog yet again. I’ve been moving to different platforms over the past several years, I’ve tried WordPress, Umbraco, Ghost and Jekyll, but seems that I have to settle with WordPress for now.
Jekyll has actually been great for what it was, it was simple, you created your template files, standards css and js – you know, the normal front-end setup, and it worked beautifully.
The thing that made Jekyll stand out for me was the performance, it’s plain ol’ HTML, no crazy scripts that execute a lot of things in the background and spitting out HTML – it’s literally just serving plain HTML with nothing in between. This came with some downsides, however – some downsides that maybe wouldn’t really matter for everyone, but they matter to me.
Why I stopped using Jekyll
The main problems that I had with Jekyll were to do with the workflow you had to adopt in order to work with it.
1. Naming files with dates
Now, this is an easy one, but still, it consumes a bit of my time as I have to remember how the date needs to be formatted, and I also have to duplicate this in the blog posts yaml meta data, which doesn’t really make much sense. I also have to add an extra step of having to change these dates before I publish as I want to show the publish date, not the date when I started writing a post.
2. Using images can be a bit of a pain
The thing with Jekyll is that everything is done through plain markdown, which is a good thing and a bad thing at the same time – in this case, managing images can be a bit of a pain. I like making sure that images used are compressed and this isn’t something Jekyll provides by default, you would normally use a 3rd party Software (CLI and GUI) and compress images as part of your publishing process which again, sounds like an added step to the process that I don’t really want to deal with each time.
3. SEO
Having to define everything in YAML to make sure that I’ve tweaked everything for Search engines, Social media etc. is something that I like being able to do – Jekyll doesn’t provide this by default, so you have to do this yourself using the templating language. Nothing too drastic, but I wish Jekyll came with this by default.
4. git is cool, but not unless it’s for collaborative purposes
I have a love and hate relationship with using git for maintaining a blog, as a Developer, I love git, but in this case, it’s just an extra step to the publishing process. I write draft 1, commit, draft 2, commit etc. do some final edits and publish. I find that this becomes a bit pointless as it just adds unnecessary steps to the process.
5. No backend can have some downsides
Not having a backend means I have to work with some limitations – not being able to add custom functionality that would require a backend such as a search functionality, not being able to have a UI for managing more complex content such as SEO meta data, built-in content analysis tools, maintaining tags without having an external list somewhere for me to lookup – these things add to a positive user experience for me.
Things that I miss from Jekyll
1. Speed
Definitely the biggest thing that I miss is performance, but hey ho, you can’t win them all. I did try to make up for that by barely using any plugins, in fact, I only use essentials, everything else is done as custom functionality in the theme itself. All cache options are turned on, everything is minified.
I rewrote the css to use a completely custom stylesheet using sass and dropped bootstrap altogether. The markup was also reduced, I’m not using jQuery, in fact, I’m only using JavaScript for code highlighting and share buttons which looks like this:
;(function() {
var shareLinks = document.querySelectorAll('.post-share-links a');
for(var i=0; i < shareLinks.length; i++) {
var shareLink = shareLinks[i];
shareLink.addEventListener('click', function(e) {
e.preventDefault();
var href = this.href;
window.open(href, 'Social Share - ThinkProgramming', 'width=500,height=400,resizable=no');
})
}
})();
2. Blogging with preview offline
Previously with Jekyll, if I wanted to preview a blog post, I could just run jekyll serve --drafts and I get a preview of how my post would actually look like without being connected to the internet, this was very useful when travelling. This is no longer an option without having everything installed locally.
3. Not having to switch between editors
All Markdown editors in WordPress are all terrible, so I prefer using a dedicated Markdown editor – so now, I have to keep copying and pasting between WordPress’ markdown editor and a dedicated markdown editor which isn’t an ideal way of working… hey… I just found a gap in the market.
4. Quick and easy way of previewing changes
This is really where git shines, I could see what I’ve changed very easily, WordPress really isn’t great for this, it’s really really slow, it’s so slow that it’s painful to use.
It’s all about trade offs
Every single platform has their pros and cons, I’ve chosen WordPress as my platform for at least the next few years to come, it’s mature, huge eco-system, if you’re familiar with PHP, you can do pretty much anything you want with it – there are the cons as mentioned, but and it’s definitely far from being the best, but nor is it the worst, it just works for my particular case because of how I like my workflow.
What I would love to see would be a customisable Jekyll back-end via YAML or some other mechanism where you define the fields that you want and it’s type i.e. Wide image of background, og: meta’s etc. for easily managing content. Manage assets and image compression and maybe even a git commit button.
