Cross-posted from: http://harlankellaway.com/2014/02/20/web-development-beginners-tradeoffs-jekyll-wordpress/ (February 20, 2014)
I’ve used WordPress for years as the base for just about every site I’ve created. It had occurred to me occasionally that WordPress may not be the best choice in every website development case, whether big or small, simple or complex. But, honestly, the idea of creating a website that didn’t have a database behind it hadn’t even occurred to me. A website that is almost purely HTML? I had subconsciously equated this with broken links and scrolling banners. I had equated database-backing with words like easy, maintainable, modern, and extensible.
It’s a clear case of every problem looking like a nail when the only tool you have is a hammer. But what if your problem is a thumbtack? Or a staple? A hammer might work, but it’s most definitely overkill and can even limit your creativity in solving the problem of fastening paper to things.
In terms of website development, WordPress has been my hammer and it’s gotten the job done. But, I had the opportunity the past weeks to use a new tool — Jekyll.
Jekyll is, in the creators’ words:
…a simple, blog-aware, static site generator. It takes a template directory containing raw text files in various formats, runs it through Markdown (or Textile) and Liquid converters, and spits out a complete, ready-to-publish static website suitable for serving with your favorite web server.
In other words, Jekyll converts simple text files (organized in a certain fashion) into all of the HTML (with supporting files such as CSS files and images) necessary for a website. Just those files. No database.
What internet browsers (such as Firefox, Chrome, Safari, etc.) do is interpret certain file formats – most well-known being HTML – and convert the text in those files into graphically designed websites. Meaning browsers need to be fed HTML pages – whether those pages were generated by Jekyll or through an application translating data from a database.
The simplicity Jekyll offers — of not having to deal with databases and their languages — may sound like a dream-come-true for those of us who find database work daunting or difficult. To someone like me, who’s so accustomed to databases driving websites, it really did feel like a breath of fresh air to work with it.
Very basically, a utility like Jekyll and a system like WordPress are two very different means to an end — with that, I thought I’d offer thoughts on trade-offs between the two to help those beginning with either or both.
Dynamicity
What Jekyll does is generate static (not dynamic) sites. Meaning, the files that make up your website already have all of their content before a web browser interprets them. Alternatively,dynamic sites generate the content you see through interactions with the database backing them, often through user interaction.
Examples of obviously database driven sites might be Amazon, Ebay, Facebook. But what about, say, a personal blog with one About page?
The Learning Curve
There is a learning curve to Jekyll and to WordPress. Both involve potentially learning multiple technologies depending on how deep you want to delve into customization. Briefly, here are some of what one might have to versed with to get into the guts of either:
WordPress – PHP, database queries, WordPress plugin concepts
Jekyll – YAML, Command Line/Terminal use, Liquid (minimally), Markdown (optional), Git & GitHub (optional), Ruby (optional)
You may not have even heard of all of the latter group – and that can be daunting in-and-of itself. However, you don’t need to know much of any of these things to get far with Jekyll. That being said, Jekyll can only go so far without third-party extensions.
Do you want comments on your blog? Do you want users to be able to sign up for email notifications of your posts? Do you want social media links that display how much your content is being shared? Do you want users to be able to search your site? You have to find third-party tools (e.g. Disqus, Feedburner, AddThis, Google Custom Search, respectively) with desired functionality that can be integrated into an HTML based site. With WordPress, a lot of this common functionality is already built in – you don’t even have to think about it.
Extensibility
Widgets and Plugins. These are the discrete modules that allow you to add additional functionality to a WordPress sites. Widgets are bundled with any WordPress Site and plugins are created by developers and available for download as needed. Plugins are great – but they’re traditionally plagued by becoming broken as the WordPress core is updated and the (unpaid, often) developers who developed the plugins don’t take the time to update them. Just the fact that developers are needed to make these plugins illustrates the complexity of building additional functionality into WordPress.
Jekyll has it’s own system of creating simple plugins. However, plugin development for Jekyll is not nearly as active as that for WordPress, so it’s very possible you won’t find the plugin you need (currently). As mentioned, 3rd party tools are often necessary for Jekyll sites to increase functionality that is not possible without dynamic database interaction.
Another facet of extensibility is how flexible the look of your website is – and, Jekyll is ultimately much more malleable. With WordPress, often users download a pre-created theme that pre-designates what kind of widgets can be used where. Users then customize the theme they choose, often in ways dictated by the theme (another signifier of how complicated it can be to build on the core functionality of WordPress). With Jekyll, you create what you want yourself (of course, you can use HTML + CSS themes that are available to help you out) – this is a challenge, but can be very freeing to those who like ultimate control of how things are layed out.
Community
My last brief comparison will be on user community. Both have active online communities. WordPress’s at this time is undoubtedly larger given its pervasiveness. I’d say that the way the two are maintained dictates the tones of their communities and where they gather to relate. WordPress’s main forum is arguably more structured but its community at-large more widespread. As mentioned there’s a large community of independent developers who produce WordPress plugins. Users communicate on WordPress forums which probably gather new users every day.
Jekyll is an open source project that is hosted on GitHub and is promoted by GitHub itself (who uses it extensively) – thus the open source and GitHub communities and their qualities permeate discussion around Jekyll. For those new to Jekyll, this can be a con and a pro. If discussing open source projects or GitHub or Linux makes you anxious, if you’re intimidated by StackOverflow or aren’t enthused about potentially figuring out problems that haven’t already been posted online by hundreds of people, Jekyll may not be the best choice. On the other hand, this is a community that is tighter knit and can be extremely helpful and quickly responsive to issues – and you can even influence bettering the tool you rely on!
These are all tradeoffs between two options that have their own virtues – and they certainly aren’t the only tradeoffs. My own personal impression is that Jekyll is a good idea for beginners not daunted by command-line tools looking to create websites that are simple. Once you are clear on how to get your Jekyll site up and you have your personal workflow for developing it, it’s fairly straightforward (and fun, even!). However, if you know you need a lot of dynamic information or you’re easily frustrated with integrating third party tools into websites, or you’re used to the WordPress interface — that makes WordPress a solid choice too (same goes for Joomla, Drupal, etc.).
Personally, I’m moving from WordPress to Jekyll as I feel a greater need to control more aspects of my own (very simple) site. You can check out my current WordPress site at http://harlankellaway.wordpress.com/ and a site I made using Jekyll at http://hkellaway.github.io
Happy coding!
This blog is licensed under Attribution-Noncommercial-Share Alike 3.0 Unported license.