Jekyll doesn’t do components? Liar!
Tags: webdev, jamstack, jekyll
Published: 2022-02-23 15:34:56

---
title: Jekyll doesn’t do components? Liar!
published: true
date: 2021-09-09 15:00:00 UTC
tags: webdev,jamstack,jekyll
canonical_url: https://katiekodes.com/jekyll-components-wysiwyg/
---

Hot take: anyone who tells you that Jekyll doesn’t support component-based design, and that you need a React- or Vue-based [static site generator](https://dev.to/katiekodes/what-is-a-static-site-generator-350o), is wrong.

1. Any basic fragment-of-HTML “component” you can define with JSX in a file and then cross-reference as `<MyComponent key="value" />`, you can just as easily define with Liquid in a file and cross-reference in Jekyll as `{% include MyComponent.html key=value %}`.
2. Any basic fragment-of-HTML “layout” you can define with JSX in a file and then cross-reference as `<MyLayout>Hello, world</MyLayout>`, you can just as easily define with Liquid in a file and then cross-reference in the front matter of a Jekyll template as `layout: MyLayout`.

## Example

Remember my “what you see is what you get” [_(“WYSIWYG”)_ componentized Squarespace-style “site builder”](https://dev.to/katiekodes/gatsby-react-wsyiwyg-cms-friendly-markdown-1npm) I learned Gatsby so I could build last year?

I didn’t actually need Gatsby – here’s the [source code in Jekyll](https://github.com/kkgthb/web-site-jekyll-03-wysiwyg), and ta-da, [live site](https://jekyll-wysiwyg-site-builder.netlify.app/).

![Screenshot of a basic componentized site, before and after editing](https://katiekodes.com/images/header-gatsby-movable.png)

### Drag-and-drop

Need to see with your own eyes that it can have a drag-and-drop CMS experience? [Click around this theme in Stackbit and see.](https://app.stackbit.com/create?theme=https://github.com/kkgthb/web-site-jekyll-03-wysiwyg)

[![Create with Stackbit](https://assets.stackbit.com/badge/create-with-stackbit.svg)](https://app.stackbit.com/create?theme=https://github.com/kkgthb/web-site-jekyll-03-wysiwyg)

* * *

## Why Jekyll isn’t perfect

Okay, actually, no one’s _wrong_, per se, and certainly not _lying_, about newer SSGs _(and their templating languages)_ helping you develop components easily.

I just wanted to point out that componentizing a site so that you can give content authors a Wix-like drag-and-drop experience comes from:

1. architecting a data model for that purpose
2. architecting your static site generator templating for that purpose

You don’t need a JavaScript-based SSG or a “hydrating” SSG or a “modern” SSG or anything of the sort to do really fancy things with “components.”

“Components” are a **way of thinking** , not a property of a specific SSG templating language.

However, there are some _related_ problems you might run into like:

### The syntax can be heavy

Liquid doesn’t _really_ love objects & arrays – particularly not making it easy to instantiate them as literals.

As soon as you want to pass around particularly complicated structured data, or do any fancy preprocessing of it, the amount of Liquid that you have to write really starts to explode, compared to the amount of JSX or Vue.js templating code _(which JavaScript – including NPM package imports – slips right into natively)_ that you have to write.

#### But also, the syntax can be light

That said, when you _don’t_ have heavy computation to do, I find Liquid’s plain-HTML-like syntax _much_ cleaner and more concise than React’s or Vue’s templating syntaxes, which is why I’m defending Jekyll in the first place.

Here’s what a basic component looks like in React:

```jsx
import React from "react"

export default function Home() {
  return <div>Hello world!</div>
}
```

Here’s what that same component looks like in Liquid:

```html
<div>Hello world!</div>
```

### The Jekyll ecosystem is small

#### It’s not JavaScript all the way down

When you’re using Jekyll, any custom _computation_ you need that exceeds the power of Shopify’s Liquid templating language has to be defined in the Ruby programming language.

I’ll admit, it’s really nice to use **one** programming language – JavaScript – in:

1. The front-end code you deliver to site visitors’ browsers alongside your HTML and CSS _(in Jekyll, that’s JavaScript)_.
2. The HTML templating code _(in Jekyll, that’s Liquid)_. 
  - Jekyll _won’t_ let you randomly call Ruby’s `.map{}` within Liquid template code. You have hand-add Ruby code to the Liquid specification as a “Liquid filter” using Jekyll’s “plugins” functionality.
  - React/Vue-based SSGs, however, _will_ let you randomly call JavaScript’s `.map()` within their templating languages, because it’s built into the syntax of the templating languages themselves that you’re allowed to do that.
3. Deep-back-end functionality _(in Jekyll, that’s Ruby)_.

#### NPM > Gems

Let’s be honest, these days all the cool stuff – particularly for supporting web site generation – is an NPM package, not a Ruby Gem. Like libraries that:

- [Import content from Sanity CMS](https://www.npmjs.com/package/@sanity/client)
- Render front-end HTML & CSS & JavaScript that [embeds a video player into your web site](https://www.npmjs.com/package/react-player)

### Content editing tools are scarce

#### Headless CMS is tough

Jekyll is old, and it doesn’t bake in a presumption that you’ll be fetching external API-based headless CMS data into your build the way Eleventy does.

To use data from Sanity, Contentful, the Notion API, the Wordpress API, etc. you literally have to run _(and possibly hand-write)_ code that dumps API-sourced data into files on your filesystem that Jekyll _can_ understand, _before_ running `jekyll build`. _(A couple of pre-written libraries: [jekyll-contentful-data-import](https://github.com/contentful/jekyll-contentful-data-import), [Sourcebit](https://github.com/stackbit/sourcebit).)_

You can 100% build a really well-componentized theme in Liquid, as I’ve shown above. But the whole point of building a componentized theme is to give people a Wix-like experience through a drag-and-drop [GUI](https://en.wikipedia.org/wiki/Graphical_user_interface) editor, and most of the [good content management user interfaces](https://dev.to/katiekodes/choosing-a-headless-cms-without-losing-your-head-3ef9) are built into API-based headless CMS websites.

#### Few Git-based CMS options

There are drag-and-drop content editors that play nicely with storing your content in the same Git repository as the site’s template codebase, like Netlify CMS and Forestry.io, but they’re not truly WYSIWYG experiences.

- TinaCMS is a Wix-like experience, but it doesn’t support Jekyll. From what I can tell, it leverages the front-end code that newer site generators like Gatsby and Next “hydrate” into the “DOM” to support its drag-and-drop functionality.
- The only Wix-like experience I’ve found so far that supports Jekyll is [Stackbit](https://app.stackbit.com/create?theme=https://github.com/kkgthb/web-site-jekyll-03-wysiwyg) … but who knows if they will forever? I can’t imagine that adding a live-edit drag-and-drop skin to Jekyll’s `localhost` engine has been easy for them to code, as amazing of a gift to the world it’s been that they figured it out.