Migrating from Jekyll to WebOrigami

Apr 8th, 2026 -Ben

They have slightly different philosophies. WebOrgami is much more direct, while Jekyll has layers of configuration. WebOrigami is very attached to file extensions while Jekyll’s are all wrong (markdown and liquid in html or md??)

What I’ve ended with is spiritually something in between Jekyll and WebOrigami. But because WebOrigami is so flexible, it’s all written in it! I wasn’t rely much on Jekyll, really, so this process took me a few hours over the course of a week or two. These steps are ordered in the way I wish I would have done it.

First step, change all the filenames. I haven’t found a better way than to just rename then on the system. Everything became .liquid so I could use a file loader for it.

Second, adapt Jan’s Liquid handler. I’ve made it load much closer to what Jekyll expects, and return an object with the front matter too. My loader creates all context for the Liquid rendering, renders that, then gives me back the document with its front matter. The document’s body might be markdown or html, but the handler doesn’t care. For the markdown files, I manually call Origami.mdHtml later on.

Writing the Liquid Handler was probably the most difficult part for me. I think the intention might be that a loader is able to turn an arbitrary file into a function that returns something you can post on the web. I’m not sure, but all the loaders I’ve seen do that. I think mine still works well within WebOrigami’s system because it returns a tree like many of the examples on their site. Jekyll builds a lot of context for you, I had to move that to the handler. I definitely took some shortcuts. My blog was 3 layers deep at its thickest and I think I relied on a small subset of what Jekyll really provides. All the special Jekyll tags I use needed to be added to the Liquid rendering engine, but I only used post_url . Since I’ve created my own post hierarchy now, I just interpolated it directly there, half a step from hard coded. Returning a tree from the handler instead of text only was my biggest enabler. Once I had the posts’ front matter available to me in my site.ori file, I could do many more interesting transformations on the data.

Including, moving metadata into front matter. This was part of making the blogging system my own. I don’t like the naming convention required by Jekyll. Instead of recreating it in WebOrigami, I added title and date properties into the front matter. I didn’t taken the time to make the URLs match, sorry about that lapse of judgement. Since I made the file handler return the front matter to me, I have all the metadata I want, and WebOrigami makes the transformations easy. I’m not sure if I’ll use Obsidian or Sveltia to write these eventually, but the front matter should be easy to add in both.

Lastly, porting all the other Jekyll extensions and add ons. I really only relied on the feed_xml for an RSS feed. WebOrigami uses a JSON Feed to RSS converter and has a very nice tutorial on how to create a JSON Feed. Now I have both!

Future Plans

I can do so much more with this now. I never learned Jekyll’s tagging system, I didn’t take the time when I had so few blog posts and committed to only blogging on tech subjects. But now I can build that myself, and it can be as lightweight as I want. With WebOrigami easily traversing the file system and yaml and any sort of tree, I don’t expect it will be that hard.

I’ve changed the file names on my posts, which is a decision I made thinking not too many people actually come to my site. Eventually, they will probably change again. I’d like to allow them to be organized by year and maybe month.

This is what it looks like, with a single .ori file. Two if you count the configuration.

Overall, I’ve had a fun experience with WebOrigami. It’s being actively worked on and you can read all the comics to learn more about it. They have a great community to chat with. The Tree mechanism is really an incredible one!