The present

It is very easy to point a finger at an existing project and shout “problem”. As a newcomer to the project I had a good chance to trip over the little quirks and now I do the easy thing: “problem!!”.

This page discusses enchantments and quirk fixes that would break the API of jekyll.

Definition for this discussion: The API for jekyll is the `site` object and all children.

jekyll with a software engineers eyes

Jekyll is a great tool for programmers that want to write their blog in “a programmers way”. With a rather small API jekyll still provides sophisticated possibilities for bloggers and programmers alike.

Some points of jekyll API are – in my eyes – hindering jekyll to fully unfold its potential. These issues basically fall in one of the two categories:

• Missing objects (like category, see #29)
• Tight coupling with the filesystem (like the whole filename discussion in #30)

Fixing these issues while maintaining the existing API is difficult at best and leaves the bad after taste of a hack. And I don’t mean the “look at this amazing thing I hacked” kind of hack.

The future: Refactoring to a strong domain model

Breaking the interface of an existing application should not be done with levity. Each break causes many, many changes for running installations. And this means many, many angry users.

Still, I think that some changes would carry such a great benefit, that they are worth the trouble. These changes are (dear reader, please add to the list)

1. Making `category` a first class citizen, see issue #29 for an example
2. Decouple the domain model from the filesystem layout. See issue #30 for one example
3. Default layouts in _config.yml, see issue #25
4. …

The idea is to discuss specific changes/improvements as issues and link to them from here.