The Immediate Future of Jekyll
blog.parkermoore.de
blog.parkermoore.de
If you already have a blog based on Jekyll, but feels it takes forever to build. Consider switching it to Punch with this boilerplate (https://github.com/laktek/punch-blog). Basically, you only need to move the files from Jekyll's `_posts` directory to Punch's `posts` directory. Also, you would love the ease in template customizations (and ability to use partial layouts).
Jekyll's meant to be a static blog generator, not a general static site generator.
I used to be a happy jekyll user for a long time. But, bloggin using jekyll
is frustrating when you have to make a lot of minor edits. The commit → push
dance is too much while making small edits. Also, I don't know a straight way
of doing jekyll redirects and allowing the use of tags/categories.
Substance fixes those issues because it is dynamic I sometimes wonder what age
we are living in, when we (the tech bloggers) use a static site generator for
our blogs. Jekyll's main strength has been that it's very very flexible,
I've tried to build Substance to give the most flexibility to the users
without complicating things.
Substance (http://substancehq.com/) is a simple blogging engine / site builder without any fluff. I created it to replace Jekyll for myself. Hope others find it useful.Also, it has ability to add custom data collections easily. If you want to build a simple site, this comes in very handy.
https://github.com/darwin/terraform
The main trick is to use PhantomJS to pre-generate static site for initial serving.
But when I'm writing a blog post and I constantly want to preview it in the browser (since lots of my posts have images and such I prefer seeing the real layout than purely in sublime text 2) I use a rake task I have that stashes every post but the one I'm working on so it only generates the one post.
Edit: and a faster generation time means I don't have to feel bad using lots of liquid filters / includes (which can help clean things up and organize my site).
Two things I'd like to see (which I've had to fork my jekyll for) and that I'll put on the github:
- "multiviews" support (it's how I get all my links to have no .html ending, well that and some rack:rewrite rules)
- support for different post types that are not in the main site.posts. I only have 2 types now but for a while had a regular post, a shorter "aside" style post that was not in the main feed nor homepage and had its own index and feed, and another post type for photos. These go beyond just different layouts. Though this is more of a CMS feature than a blog feature which may be a direction thing that Jekyll is not intended for. ?
I fail to see how changing a typo in an article's content would require the whole thing to be rebuilt. Even adding a page would not require rebuilding every single page unless the new page appeared in a global navigation. Building the dependency graph automatically could even turn out to be not that hard.
I needed just a simple compiler which converts markdown to html while retaining the structure of the site. Ideally, what need not be processed should be left as is. This gives developers like me a lot of flexibility to design a site.
Jekyll has not been updated for a long time but it still serves my needs quite well. I hope future releases would support minification and preprocessors like Coffeescript.
As far as cost. I'm 30 and I don't like relying on free things. Github probably wont go down, but I'd still rather pay. I set that up Dec 1st, served 100k pageviews. My Amazon bill right now is $1.25 (one dollar, twenty five cents). Maybe that'll go up, but for what I'm doing, I doubt it will be that expensive.
I've wanted to for a while but I feel somewhat handicapped not knowing Ruby so I've been putzing around Python-based alternatives like Pelican.
On a side note, I also had a problem with the RSS generator. I managed to submit a patch for my problem. I was pleased to discover Ruby is so Perlish! I guess thats obvious given that a lot of Ruby is inspired by Perl. I suspect switching back and forth between the two would not be hard.