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.
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.
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.
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:
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
into Jekyll 3 so that everyone can take advantage of a hook-based plugin architecture.
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.
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
site/ folder on
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.