Jekyll 3 — The Road Ahead

First, I want to say that I have been blown away by the massive support from the Jekyll community for me and for the project in ways innumerable. Every pull request reinvigorates me to continue driving Jekyll forward as swiftly as possible. Even if I don’t accept the PR, room for improvement in the eyes of at least one user is enlightening and helps drive each decision the Core Team makes. Thank you for your support, for your patience, and for your continued excitement about Jekyll.

We held a townhall-type Google Hangout meeting yesterday. It’s about an hour and goes into much more depth than what I will say here. We’ll be hosting more, tentatively on a monthly basis.

Now, on to business.

Jekyll 2.0 was a pretty big release. Last May, we announced Collections, native Sass support, YAML front matter defaults, and many other improvements and fixes in our effort to make Jekyll the best tool for making static websites.

With Jekyll 3.0, I want to take Jekyll back to its roots: simplicity, extensibility, and speed.

1. Simplicity

Using Jekyll

Jekyll should be easy to use, and problems should be easy to address. Cryptic warning messages should instead be replaced by coherent, direct verbiage. Creation of new content should be as easy as running jekyll generate (and jekyll g for the truly lazy ). Any changes we introduce which are backwards-incompatible should be accompanied with a compatibility layer and a clear, direct deprecation message. We should be doing everything we can to ensure that the path to accomplishing a particular goal in Jekyll has as few steps as possible and is as stupid simple as possible.

Key to this is that Jekyll is a content creation and publishing tool, and therefore should be focused on making creating and publishing as easy and direct as possible. Sane defaults paired with optional flexibility allow for the best possible mixture of customizability and out-of-the-box functionality.

Installing Jekyll

If you’ve ever installed Jekyll, you know what it takes to get that beast up and running: Python, Ruby, usually a Ruby Version Manager, Ruby development headers, Xcode on the Mac, Node, etc. There are a lot of dependencies.

I’d like to focus on:

• Removing most defaults, giving you just what you need for the average site
• Removing dependencies on other languages/runtimes – leaving just a couple C extensions
• Integration with Liquid C as optional for performance gains
• Simplifying the internals and the abstractions (posts will become a collection)

2. Extensibility

Sometimes, Jekyll just doesn’t cut it. The core components work fine, but you have a particular use-case that requires an extension to Jekyll. As of right now, you can either write a Converter, Liquid Tag or a Generator. That’s it. But what if you could hook into various parts of the pipeline, as your content is turned into a static site? What if you could create your own hooks? With Jekyll 3, we’re reimagining the plugin interface, while maintaining the old interfaces.

To accomplish this, we’ll be writing new feature ideas as plugins and shipping them separate from the rest of Jekyll. If they are useful to the vast majority of users (> 85%), then we’d include that plugin as a runtime dependency. Nevertheless, the core idea here is that in order to create the best possible plugin system, we need to be using it ourselves and iterating.

I have been heavily influenced by the work of Brandon Mathis, the creator of Octopress. He managed to work around all the warts and pain points of Jekyll to create a fantastic development experience. I’d love to incorporate some of his ideas, like Octopress::Hooks, into Jekyll 3 so that everyone can take advantage of a hook-based plugin architecture.

3. Speed

Jekyll can be slow. Some blame Ruby, others blame Liquid – needless to say, there’s plenty of blame to go around. 3.0 will feature some extraordinary speed-ups, with (optional) Liquid-C integration, incremental regeneration and optimized object handling. We’re running benchmarks on every piece of code we can think of to try to find ways to speed up the generation process.

So there are my thoughts on Jekyll 3’s driving principles. I’d love to see you around, and hear from you either on GitHub or at my personal Twitter account.

We’re also going to try to put out more official video and written content. Our documentation website can use a lot of work. If you have the time, it would be fantastic if you could pick a page and rewrite portions of it or restructure it altogether to make it even more helpful. Submit those pull requests to the master branch – the jekyllrb.com site source can be found in the site/ folder on master.

We have Jekyll 4.0 plans in the works as well (they were 3.0 plans… long story), and those are even grander, and I can’t wait to share them with you all.

Happy Jekylling!