Experimenting with Jekyll

One of the interesting aspects of the latest Res.im site refresh was the choice to use Jekyll.

As a quick introduction for non-developers, Jekyll is a static site generator, meaning pages are rendered as static files rather than dynamically from a database. When you visited this post on the Res.im site, your browser asked our server to send it the page and the server sent one response. When you read a blog post published on a WordPress site, for example, your browser has a longer conversation with the server to generate different elements (such as post title, post content, author name, publication date, categories, etc).

I sat down with Heather Vandervecht, Front-End Developer, to chat about why and how the team used Jekyll and what she learned in the process.

B: How did you decide to go with a flat-file site generator?

H: I knew I wanted to do flat-file. Because we have a blog you’d think WordPress, but I knew flat-file was faster and I wanted to try something different. That was the big thing for me. The fact that it was our site offered an opportunity. Jonathan is open to trying suggestions and I could kind of stretch what I knew and teach myself something with this project as well, which is always my goal.

B: Explain a little more about what you mean by flat-file being “faster.”

H: Load times. Comparing Jekyll and WordPress, when you go to a WordPress site, most of the content is pulling dynamically, so it has to make calls to your server for all that content. But the way Jekyll works is it’s all technically hard-coded. When you create a post in Markdown or just a text file, Jekyll will compile all of the source folders and literally hard-code the site. So when you visit a blog post it’s technically considered a static page. It loads the page and has to load image assets but it doesn’t have to call all of the content.

B: Why Jekyll? Did you look at any others?

H: My first assumption was PicoCMS – I’d heard of PicoCMS and a few other flat-file CMS’s before from other developer friends – but I realized quickly that it didn’t offer what we needed. It was actually too simple, so I had to go a step further. I had heard of Jekyll but shied away because as a static site generator, it seemed almost too complex for what we needed. But when I realized that Pico wasn’t going to work I thought, “alright Jekyll could be an option.” There was a learning curve to using Jekyll – using its tags and things like that – but getting into it I realized, “this is exactly what we need, let’s jump that learning curve.”

B: How exactly was Pico too simple? What was it lacking?

H: Plugins, mostly. Pico and Jekyll are the same in the sense that they offer a really straightforward folder structure and it uses the same language, but there’s more of a community around Jekyll. It’s open source so people create plugins for it, which you can download. Pico didn’t have as much of a community around it, so when I needed functionality I would’ve had to code it from scratch. Jekyll offered more of those plugins that already existed. And it had excellent documentation – it was amazing to go to the Jekyll website and read the documentation.

B: What were the biggest challenges?

H: Jekyll is written in Ruby, which I’ve never worked with before – all of its plugins and everything, just like WordPress is all PHP. I essentially had to teach myself basic Ruby to understand how plugins work. I like to understand – when I install a plugin into a website I like to know how it works. And then just the logic of setting up the website functionality, because we’ve done some really funky things with the website, like infinite scrolling and things like that – things that Jekyll doesn’t do by itself, so I had to use plugins to make it work and understand how the plugins tie into it – so it was really interesting. There were so many pieces of functionality that I’ve never done before.

B: Was there anything else you wanted to but weren’t able to do?

H: No, actually. Personally, the goal of the site for me was to push my boundaries as a front-end dev, which the site did from the beginning. And then infinite scrolling was another thing I wanted to do. And I also just wanted to keep my code as clean as possible. That’s probably different from Diana’s goal as the designer, and Jonathan’s maybe – but my goal for the site was for the front-end piece to be something I was proud of and to say, “I worked on this – this piece of functionality exists because I coded it.”

B: Do you have any recommendations or advice to anyone considering Jekyll or another flat-file alternative?

H: It’s interesting. It’s improved my skills as a developer to be able to work with a flat-file site vs. a database CMS now. I think if someone’s considering it they need to figure out exactly what functionality they need for their site, and then make sure that whatever they use covers that so they don’t waste time. If a flat file CMS or a static site generator covers all their needs then I think they should 100% go for it, because I think the pros are by far worth it.




On


Development Tech Experiments

Ready to work together?

Reach out with questions or to get started on your next UX research or product design project. You’ll hear back from us within a day.


Contact us