Creating a Faster Jekyll
We did however run into performance issues so we wrote a replacement which is semi-compatible with Jekyll but with better speed and some additional features
servewill generate content as requested by the browser (lazy evaluation), this allows instant previews as the full site doesn’t have to be built first. It also means that if there is a (syntax) error generating a page, the error will be shown in your browser and the error page even supports automatic reload. Another advantage of this approach is that during testing we do not write anything to disk, so
_sitewill always contain deployment-ready pages (no instances of
localhost:4000, injected reload scripts, or unpublished drafts).
buildwill make use of multiple tasks to parallelize content generation. Our site took almost 10 seconds to build with Jekyll which we have now reduced to 2-3 seconds (this is on a 2.8 GHz Macbook Pro from late 2013).
Collections have been generalized so that they all support both tags, categories, drafts, and arbitrary sorting (e.g. reverse chronological). There is nothing special about
Support for multiple domains has been added. This means generating content for
blog.example.orgcan be done using the same project, so that resources can be shared and cross-linking is possible via the
Extensible render pipeline: Content is transformed using a pipeline where it is trivial to add new filters, this allows adding new converters, override the default converters, or simply pre/post-process content to support custom syntax, inject content, run the generated HTML through a validator, or similar.
Easy pagination of both collections and data structures.
Collections can have pages generated for tags and categories. Making this a built-in feature makes it possible to iterate generated pages and link to these using their
urlproperty rather than make assumptions about where such pages end up in the file hierarchy.
Any change to a site file, be it files under
_config.yml, will trigger a browser reload that will fetch the updated page. This is possible because we use lazy evaluation, so a file system change is effectively just triggering a cache flush, rather than having to rebuild the entire site.
Default values for pages can be set using file globs, making it easy to use the same set of values for a broad set of files, and default values for collection files can be set under the respective collection, which is extra useful when using cascading configuration files.
source_dirsetting to allow putting site content in a subdirectory, obviating the need for maintaining a list of excludes and/or prefixing non-publishable items with underscores.
Since this was started as a reimplementation of Jekyll, let’s use Jekyll to build the initial site scaffolding:
jekyll new awesome-site
Add Glim to the generated
cd awesome-site/ bundle add glim
And then test the site:
bundle exec glim serve --open-url
If you are using TextMate then install the
glim-edit-in-textmate plugin like this:
bundle add glim-edit-in-textmate --group=glim_plugins
serve command and in your browser you will be able to press e to open the source for the current page in TextMate.
This uses the
txmt: URL scheme so your browser will ask for permission (the first time, depending on browser).
If you don’t want to use a
Gemfile then you can install
glim using the
gem install glim
glim help to see what commands are available.
Detailed information about the syntax for the features mentioned above can be found in the glim manual.
While compatibility with Jekyll was a goal for the first version of Glim, this is not a long-term goal, and we do consider breaking some of the existing compatibility.
For example with Jekyll, using
:title in a permalink,
page.title in a template, or
post.title when iterating over posts, can result in 3 different values for the same page. This inconsistency adds code complexity and makes it harder for the user to understand the rules.
Another example is the API names, there are getters for
docs. This again is inconsistency that makes it hard for the user to understand what type of files are returned by the respective getters.
Since we cannot offer 100% compatibility with Jekyll, we may as well make a clean break and clean up these things.