Using Jekyll for rapid prototyping

Lucas Lemonnier
Prototypr
Published in
6 min readSep 4, 2017

As a front-end designer, I increasingly find myself working on UI/UX projects and design systems (styleguides). There is no debating the fact that the toolset, frameworks, and configuration for front-end projects have gotten pretty complex: Gulp, Webpack, transpilers, PostCSS, CMS, Servers… the list goes on and changes frequently.

Some or all of these will be necessary for building out a validated project, but during the design/experimental stage I really like to keep things lean. Straightforward HTML/CSS/JS allows me to just dig in and spend my time designing and coding up demos, rather than wrestling with build tools.

Minimal needs for rapid prototyping:

This lean dev environment should still provide me with a few tools to maximize timelines and client budgets. While I may add features specific to certain projects, there are 5 must-haves for every project to make me productive:

  1. Templating system
  2. Accessing and storing data
  3. Variables
  4. CSS preprocessing
  5. LiveReload and AutoPrefixing

TL;DR: If you’re curious about why I consider these so important, I’ll break them down next. Otherwise, go try out the starter project I created.

1. Templating system

This allows me to keep my code dry. For example I might have a user settings menu which gets called into different views or even multiple times within a single view. A templating system allows us to create a partial (e.g., user-nav.html) which we can then include into different templates.

Partial (user-nav.html):

<nav class=”user-nav”><!-- ... --></nav>

View (logged-in.html):

<html>
<head><!-- ... --></head>
<body>

<header class="main-header">
<nav class="main-nav"><!-- ... --></nav>
{% include user-nav.html %}</header><!-- ... --><footer>{% include user-nav.html %}</footer></body>
</html>

Final output:

<html>
<head><!-- ... --></head>
<body>

<header class="main-header">
<nav class="main-nav"><!-- ... --></nav>

<nav class="user-nav"><!-- ... --></nav>

</header>
<!-- ... --><footer><nav class="user-nav"><!-- ... --></nav>

</footer>
</body>
</html>

If you’ve ever built a WordPress theme with template-parts or used SASS partials, this concept should be familiar.

2. Accessing and storing data

I need a way to populate templates with real or dummy content using basic control flow statements (if, if else, and for loops). Example use case: a project calls for an FAQ. Rather than hard code that entire list, I can pull from a file which stores all the info in some form of structured key/value pairs:

faq:
- question: "What is life?"
answer: "😳"
- question: "Creamy or chunky peanut butter?"
answer: "Chunky!"

# and so on...

From there I can use some engine to loop through it:

<ul class="faq">

{% for item in faq %}

<li class="faq__question">{{ item.question }}</li>
<li class="faq__answer">{{ item.answer }}</li>

{% endfor %}

</ul>

Output:

<ul class="faq">
<li class="faq__question">What is life?</li>
<li class="faq__answer">😳</li>
<li class="faq__question">Creamy or chunky peanut butter?</li>
<li class="faq__answer">Chunky!</li>
<!-- and so on... -->
</ul>

This keeps our source files nice and tidy. If I need to make some changes to the markup, I’m doing it on a single instance rather than on 32 line items.

It also makes it accessible for anyone remotely computer-savvy to update content without touching a line of html and without the need for a full CMS.

3. Variables

In order to make quick project-wide changes or to include dynamic content, variables are a must. For example I could define a social url in one file:

socialUrl: "https://twitter.com/username"

And call it locally in another:

<p>Find us on <a href="{{ socialUrl }}">twitter</a>!</p>

We can also user variables for dynamic content such as timestamps etc.

4. CSS preprocessing

I love writing CSS. Still, the idea of going without variables, mixins, and nesting on larger projects is inconceivable to me.

Before you devsplain that I could PostCSS all the things: yes, thank-you. But remember I want to keep my tooling to a bare minimum and I want to use tools/syntax familiar to any team I may be handing off to. For now and for my purposes, SASS is a sure bet.

5. LiveReload and AutoPrefixing

If you haven’t heard of it before, livereload allows you to work more quickly by reloading your browser automagically every time you make & save a change to your files. No more cmd/ctrl + R all day long. It's a huge productivity boost.

And while browsers are moving in the direction of dropping prefixing, it is still very much a reality to ensure cutting-edge CSS doesn’t break from one browser to the next. That’s all fine, I just want it to happen under the hood.

Jekyll the the rescue!

If like me, you kept hearing about jekyll strictly as a static blog generator, it’s actually way more powerful than that. It is a deceivingly simple file processor/smoosher built on Ruby and it ticks nearly all of the above boxes without any tooling:

  1. Templating system ✅
  2. Accessing and storing data ✅
  3. Variables ✅
  4. CSS preprocessing ✅
  5. LiveReload and AutoPrefixing ❌

That last requirement is non-negotiable for my workflow, so I did some googling around and created a little starter project which does include livereload and autoprefixing.

You can find it here and take it for a spin.

ps: Jekyll + Github = 😍

Jekyll is the very engine which powers github pages. This last point is definitely a bonus feature since most projects are developed in github repos anyway. Publishing a jekyll prototype to GH pages is literally one click away in the repo’s settings panel. From there, making changes locally and pushing live is literally just a commit away.

Dude, you could do all that with Pug & Stylus!

Indeed, I love Pug and Stylus as a templating combo. However, there are a few issues with it:

  1. The biggest show-stopper: there aren’t many teams around who use the duo which can make it awkward and costly when the time comes to handover code for production.
  2. It requires handcrafting tooling for each project (using gulp or equiv.) which is exactly what so many front-end designers struggle with.

But why a starter project?

As I started exploring Jekyll for my specific purposes, I found a few things to be annoying with out-of-the-box jekyll:

Too much…

Starting a new jekyll project using the default jekyll new my-project always spits out a blog-style starter theme which is way too bloated both in terms of style and content.

Too little…

Starting a project using the more stripped down jekyll new my-project --blank doesn't even give me a config file.

In both cases no LiveReload or AutoPrefixing.

It’s a work in progress and I will likely tweak things here and there, but if you’re a front-end designer looking for an efficient workflow without the tooling overhead, you might find this ticks a lot of your boxes as well ✌️

Useful Resources

If you’re totally new to jekyll, it might take you a couple of hours to get up to speed with the directory structure, understanding front-matter and using liquid (the templating language). However, the docs are very good and there is a large community behind it.

Honestly, it’s not too tough to get going by poking around the files and seeing what happens — it’s not heavy-duty programming. Either way, I’d say the initial investment is well worth it.

Here are a few links that helped me wrap my mind around it all:

Good luck and let me know if you hit any snags or see ways to improve this starter project!

--

--

Published in Prototypr

Prototyping, UX Design, Front-end Development and Beyond 👾 | ✍️ Write for us https://bit.ly/apply-prototypr

Written by Lucas Lemonnier

Independent Front-end Designer | Educator | Kayaker @luclemo | lucaslemonnier.com

Responses (2)

What are your thoughts?