Why Jekyll Is Right For This Site
While a static site is a perfect fit for the combination of my skill set, and the requirements of enlightenedpixel.com, it certainly isn’t a fit for every site, nor every site owner. Here’s why it is a fit for me, and why it may or may not be a fit for you.
I Don’t Need Dynamic Data
This site is comprised of pages and posts, that’s it. There are no logins, no custom functionality, no server-side processing of any kind. I long ago removed comments as they very rarely added meaning to a post. I removed my contact form as that was also very rarely used. In the case where I would want to bring back comments, I could use Disqus. In the case where I wanted to add a contact form, I could use an embeddable form from a service like Wufoo.
Needing dynamic data seems to be the biggest objection to using a static site. Dynamic data is often needed, but perhaps not as often as you might think. Just because a site is generated dynamically doesn’t mean it has to be generated at the time the page is requested. In a static site, the same dynamic generation occurs, it just occurs ahead of time. I would say most blogs and content sites are strong candidates for a static site.
I’m Comfortable Working Directly with the Code
WordPress does a fantastic job of giving non-developers the ability to create code for the web. You can browse and install themes, customize a theme, and add needed functionality through plugins, all without touching a single line of code.
The downside of the WordPress model is that the code contained within a WordPress theme or plugin can be massively bloated because it has to handle every possible user need. Bloated, complex code is hard to modify.
I’m comfortable working directly in the code, in fact, it’s my preference. Much of the benefit of WordPress is actually a hinderance for me. If you wish to use Jekyll, you’ll need to be comfortable with HTML and CSS to get a site online. Or, at least have the ability to hire that part of the process out.
The separations of content from code is fantastic in Jekyll. To write content, I simply edit a plain text file using the Markdown format, using whatever editor I like. It’s a simplification to edit plain text content, rather than manipulating the content via the WordPress WYSIWYG editor. However, once again, it’s not for everyone. There certainly isn’t any hand-holding like what is provided by WordPress.
I see the simplification as a positive, you may see that as a negative.
I’m Comfortable in the Terminal
I live in the terminal and on the command line. Here is a list of things you’ll need to be able to do from the terminal:
- You need to be able to install Ruby.
- You need to be able to install Ruby gems.
- You need to be able to run a handful of Jekyll-related commands from the command line.
- You potentially will need to be able to commit and push changes to Github.
If the above list scares you (or scares the person maintaining the site), Jekyll isn’t for you. There are many people able to publish a new post in the admin tools of WordPress, that would be lost trying to publish a post in Jekyll. It’s not hard, but it is technical and beyond what should be expected of a non-technical user.
I’m the Only One Writing Content and Making Changes
It’s absolutely possible to use Jekyll on a team, with multiple content editors. However, each member of the team will need to be competent with version control tools like Git. Otherwise, users will make conflicting changes with each other. There is no admin site to keep everyone in synch.
If my points above fits in with your mindset and doesn’t conflict with your site needs, I’d highly recommend looking into Jekyll. I think the upside is fantastic. I plan on writing about why I might not choose Jekyll, even in situations where, on the surface, it would seem to make sense.