Using Jekyll for rapid prototyping
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:
- Templating system
- Accessing and storing data
- Variables
- CSS preprocessing
- 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:
- Templating system ✅
- Accessing and storing data ✅
- Variables ✅
- CSS preprocessing ✅
- 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:
- 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.
- 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:
- Installing jekyll
- Liquid Templating Language
- Creating navigation
- Convert an HTML site to Jekyll
- Building Living Style Guides with Jekyll
Good luck and let me know if you hit any snags or see ways to improve this starter project!