I have never used Jekyll. I do, however, frequently use nanoc[1] - it takes a bit more effort to set up, but it is far more flexible, because instead of ridiculous configuration files, you are actually writing Ruby code (in a very nice DSL, might I add) that controls how each set of files is compiled.
One thing I did with it was create a Web site with recipes on it. The recipe files didn't have any actual content, everything was stored in the metadata. I had the Rules file set up so that they would run the Recipes through a layout that would expand them to HTML (consistently), then that was run through the normal page template.
It also used a preprocess rule to generate fresh items "on the fly" that serve as indices for each recipe type. Again, no content - the Rules file is set up so that the artificial items get all their content from a layout before being actually layouted with the site template.
I think Stasis is great in theory, but a few things are preventing me from using it full time. Namely that I can't pass simple options to a template engine (of which I do a lot).
It appears that you're the author. Can you offer any information on how Stasis is, in some ways, better than nanoc?
You are right. I would appreciate a fork to fix this very minor issue, but if not I will be getting to it very soon.
It can do everything nanoc does, but the execution is much simpler and much more natural. This is not just my opinion, but what I have heard from lots of people.
My apologies for the self-promotion, just trying to get the word out.
"Serve provides the equivalent of the Views part of the Rails MVC. Edit and tweak your websites on-the-fly with the Serve server. And when you are ready to deploy, you have two options. Either export to a pure HTML static site or deploy the source on any Ruby-friendly web host."
One of many interesting ways to design/build a static site. You could then basically use Jekyll as a deploy tool to GitHub pages.
As a designer, I can attest the difficulty of developing using Jekyll, b/c to see your work you need to switch on the Jekyll server, and no changes will compile until you flip the switch again. I know Octopress fixes that, but I'm still wrestling with how to ditch the included theme and build my own.
Except that Stasis has no support for on-the-fly creation of items from your Ruby code, no distinction between filters for content and for layouts, no support for non-filesystem data sources, no dependency tracking, and no metadata per item, among other things.
It may be more simple, but it is nowhere near as powerful.
You can do all of this via controllers. You can execute any Ruby code you want before each template renders.
There is distinction between filters for content and layouts, simply use the layout filename in a before block.
You can execute any Ruby you want. You can use ActiveRecord, Redis, whatever. Load YAML for metadata. None of this stuff needs to be baked in, Ruby already does it.
Ever since I installed Wappalyzer in my browser (detects what frameworks and technologies a website uses) more and more often I come across websites that I am shocked use so many backend and frontend frameworks. I'm shocked because that means they are spending unnecessary amounts of money, time and effort on hosting (e.g. Wordpress hosting), development and maintenance when the entire site would be perfectly well-served (and faster!) with static pages.
The problem until recently was that there weren't appropriate tools for the job, but this article should prove that's now changing.
I agree that a lot of frameworks are overkill, but if you put yourself in the frame of mind of a non-programming designer or a layperson who just needs to manage content on their site, using a static HTML generation tool is out of the question. I've been using octopress/jekyll recently and think it's amazing and really love it, but there's no way in a million years I could give that to a client to manage their own website.
Also, it's not really wasting time or money -- cheap shared hosting costs the same regardless of whether you're serving a php/mysql app or static html files. And setting up a wordpress site is probably easier for non-programmers than getting a jekyll setup going.
It's definitely a colossal waste of CPU power though, but that train left the station 10 years ago.
I agree, my point is mostly relevant to someone with some minimum level of technical ability. But providing a usable interface and "install" process for a static website generator is the missing piece here.
An interesting idea that I had once is a server-side application that can edit the site files, save them to Git or Mercurial, and then compile them statically and push to a server via FTP, SFTP, WebDAV, S3 API, or rsync.
DevSeed used to be one of the bigger name Drupal consultancies. They've been moving into other stuff over the last year and a half, for what that's worth.
edit: I just figured out that you probably already knew that. Cheers.
What I always found a bit annoying about jekyll (at least without plugin or forks) is that something like http://developmentseed.org/blog/2011/ or http://developmentseed.org/blog/2011/09/ doesn't work, i.e. the set of archive pages is pretty limited. You get one big one, and then a simple numeric pagination. I used some perl script ages ago (blosxom?), and it did just that.
Still, I guess I can hack that into the code somehow…
One "prepackaged" jekyll configuration that looks quite interesting is Octopress: http://octopress.org/
- No proper attribution to code that they clearly didn't write themselves. It's not that hard people.
- Time could be better spent making the Jekyll docs clearer. The time they spent creating this could have gone into official documentation efforts and creating a better default in the core
- Would be nice if they could add chuck those plugins into their own repository. That way it would be possible to add them to the plugin list I created on the official Jekyll Wiki
I also wish it had a better base template, but I'm no designer, so what the hell do I know.
Completely agree on #2, having better defaults (a base template and basic things like an archive/categories page) would make switching to jekyll a lot easier.
If it wasn't for your plugins (thanks) my switch to jekyll would have been surely postponed until i figured out how to write a plugin for the missing functionalities...
I'd like to note that while I did spend quite a while on these plugins, I used it solely as an exercise to learn Ruby. So this is definitely not the best Ruby code.
Thanks for the link, I think this might save me some time developing this myself. (Still wish this was in the default install, so that I'd have an easier time navigating other people's Jekyll blogs, especially now that they seem to enjoy another jump in popularity)
If you're interesting in this, you should also check out Octopress, which sits on top of Jekyll and provides a nice default theme, handy addons (for google site search, disqus comments, twitter/facebook sharing, etc.), and deployment scripts.
Well, they're not really Jekyll plugins -- just Javascript plugins on the front-end (hence disqus comments instead of your own database of comments, google custom search instead of your own internal search engine, etc.)
Oh, I get it. Those plugins are "compile-time" -- so they happen during the HTML generation process, before going up to github -- all github ever sees is static HTML and CSS files.
I played with Jekyll on GitHub several months ago, but as I recall, you commit your source files to the repo, and the GitHub would run Jekyll to compile them to HTML. (And send you an annoying message every time that it was successful...)
Could you have this as a two stage process? Make changes to files, push to my repo, repo hook runs jeckyll, commits new static assets, and pushes to github? This does require using a central server other than github I guess, though...
One thing I did with it was create a Web site with recipes on it. The recipe files didn't have any actual content, everything was stored in the metadata. I had the Rules file set up so that they would run the Recipes through a layout that would expand them to HTML (consistently), then that was run through the normal page template.
It also used a preprocess rule to generate fresh items "on the fly" that serve as indices for each recipe type. Again, no content - the Rules file is set up so that the artificial items get all their content from a layout before being actually layouted with the site template.
[1]: http://nanoc.stoneship.org/