09 Sep 2021


internet growth


💬 EN

Scorching take: anybody who tells you that Jekyll doesn’t assist component-based design, and that you simply want a React- or Vue-based static website generator, is improper.

  1. Any primary fragment-of-HTML “element” you may outline with JSX in a file after which cross-reference as <MyComponent key="worth" />, you may simply as simply outline with Liquid in a file and cross-reference in Jekyll as {% embrace MyComponent.html key=worth %}.
  2. Any primary fragment-of-HTML “structure” you may outline with JSX in a file after which cross-reference as <MyLayout>Hiya, world</MyLayout>, you may simply as simply outline with Liquid in a file after which cross-reference within the entrance matter of a Jekyll template as structure: MyLayout.


Screenshot of a basic componentized site, before and after editing

(Replace: see this similar “web page builder” for 11ty on GitHub.)


Must see with your personal eyes that it may have a drag-and-drop CMS expertise? Click on round this theme in Stackbit and see.

Create with Stackbit

Screenshot of editing the site in Stackbit

Why Jekyll isn’t excellent

Okay, truly, nobody’s improper, per se, and positively not mendacity, about newer SSGs (and their templating languages) serving to you develop elements simply.

I simply wished to level out that componentizing a website so to give content material authors a Wix-like drag-and-drop expertise comes from:

  1. architecting a knowledge mannequin for that objective
  2. architecting your static website generator templating for that objective

You don’t want a JavaScript-based SSG or a “hydrating” SSG or a “trendy” SSG or something of the type to do actually fancy issues with “elements.”

“Parts” are a mind-set, not a property of a selected SSG templating language.

Nevertheless, there are some associated issues you may run into like:

The syntax may be heavy

Liquid doesn’t actually love objects & arrays – notably not making it straightforward to instantiate them as literals.

As quickly as you wish to move round notably sophisticated structured information, or do any fancy preprocessing of it, the quantity of Liquid that you need to write actually begins to blow up, in comparison with the quantity of JSX or Vue.js templating code (which JavaScript – together with NPM bundle imports – slips proper into natively) that you need to write.

But in addition, the syntax may be gentle

That stated, once you don’t have heavy computation to do, I discover Liquid’s plain-HTML-like syntax a lot cleaner and extra concise than React’s or Vue’s templating syntaxes, which is why I’m defending Jekyll within the first place.

Right here’s what a primary element seems like in React:

import React from "react"

export default operate Residence() {
  return <div>Hiya world!</div>

Right here’s what that very same element seems like in Liquid:

The Jekyll ecosystem is small

It’s not JavaScript all the way in which down

If you’re utilizing Jekyll, any customized computation you want that exceeds the facility of Shopify’s Liquid templating language must be outlined within the Ruby programming language.

I’ll admit, it’s very nice to make use of one programming language – JavaScript – in:

  1. The front-end code you ship to website guests’ browsers alongside your HTML and CSS (in Jekyll, that’s JavaScript).
  2. The HTML templating code (in Jekyll, that’s Liquid).
    • Jekyll received’t allow you to randomly name Ruby’s .map{} inside Liquid template code. You could have hand-add Ruby code to the Liquid specification as a “Liquid filter” utilizing Jekyll’s “plugins” performance.
    • React/Vue-based SSGs, nonetheless, will allow you to randomly name JavaScript’s .map() inside their templating languages, as a result of it’s constructed into the syntax of the templating languages themselves that you simply’re allowed to do this.
  3. Deep-back-end performance (in Jekyll, that’s Ruby).

NPM > Gems

Let’s be sincere, nowadays all of the cool stuff – notably for supporting website technology – is an NPM bundle, not a Ruby Gem. Like libraries that:

Content material modifying instruments are scarce

Headless CMS is hard

Jekyll is outdated, and it doesn’t bake in a presumption that you simply’ll be fetching exterior API-based headless CMS information into your construct the way in which Eleventy does.

To make use of information from Sanity, Contentful, the Notion API, the WordPress API, and so on. you actually need to run (and probably hand-write) code that dumps API-sourced information into information in your filesystem that Jekyll can perceive, earlier than working jekyll construct. (A few pre-written libraries: Contentful’s gem, Sourcebit.)

You’ll be able to 100% construct a extremely well-componentized theme in Liquid, as I’ve proven above. However the entire level of constructing a componentized theme is to offer individuals a Wix-like expertise by means of a drag-and-drop GUI editor, and many of the good content material administration consumer interfaces are constructed into API-based headless CMS web sites.

Few Git-based CMS choices

There are drag-and-drop content material editors that play properly with storing your content material in the identical Git repository as the location’s template codebase, like Netlify CMS and Forestry.io, however they’re not really WYSIWYG experiences.

  • TinaCMS is a Wix-like expertise, however it doesn’t assist Jekyll. From what I can inform, it leverages the front-end code that newer website mills like Gatsby and Subsequent “hydrate” into the “DOM” to assist its drag-and-drop performance.
  • Prismic Slice Machine: semi-Wix-like content material authoring expertise, however similar subject – “hydrating” SSGs solely. No Jekyll.
  • The one Wix-like expertise I’ve discovered to this point that helps Jekyll is Stackbit … however who is aware of if they may ceaselessly? I can’t think about that including a live-edit drag-and-drop pores and skin to Jekyll’s localhost engine has been straightforward for them to code, as superb of a present to the world it’s been that they figured it out.

Additional sources

  • Parts: Server-Aspect vs. Shopper-Aspect by Sean C. Davis.
    • The elements (“contains”) in my Jekyll codebase can be thought of “Jamstack-flavored(slightly than “server-side-rendered,” which you may name “Wordpress-flavored” or “CGI-flavored”)server elements” in Sean’s vocabulary.
    • The elements I made for the unique Gatsby model can be “hybrid server+consumer elements.”

Sean and I bought into an incredible dialog about particular use instances for making the bounce from pure server elements to consumer/hybrid elements, and for him, one of many largest causes was having a web site complexity scope that tipped the scales from “Liquid is superior!” to “Liquid is so burdensome.” (See “the syntax may be heavy” / “the syntax may be gentle.”) Even once you don’t really need any client-ish-ness to your elements in any respect, there merely aren’t pure server SSGs with JavaScript as an underlying programming language that use highly effective JavaScript frameworks and don’t “hydrate” your server elements into consumer elements. Usually instances, Sean finds that an enterprise undertaking has to leap from 11ty to Subsequent simply to make use of extra JavaScript beneath the hood – every thing else that Subsequent does with hydration is only a aspect impact, from the developer’s perspective.

Sean additionally identified that whereas authoring a principal.js bundle isn’t so unhealthy if all you’re making an attempt to do is make one top-navbar come out correctly like I did for My Huong Kitchen, after getting dozens of interactive elements slightly than one or two, not utilizing an SSG that’s constructed for tightly coupling markup and interactivity, and utilizing vanilla JavaScript as a substitute of utilizing an SSG whose front-end framework provides you helpful interactivity shorthands, turns into demise by a thousand papercuts.

#Jekyll #doesnt #elements #Liar

Leave a Reply

Your email address will not be published. Required fields are marked *