I like the pushback from Katie Kodes here. I’ve said in the past that I don’t think server-side languages haven’t quite nailed “building in components” as well as JavaScript has, but hey, this is a good point:
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 aslayout: MyLayout.
Any HTML preprocessor that can do partials with local variables is pretty close to replicating the best of stateless JavaScript components. The line gets even blurrier with stuff like Eleventy Serverless that can build individual pages on the fly by hitting the URL of a cloud function.
That’s the thing though. “Stateless”. Once you need some JavaScript to change the component’s state after some event, you realize how much nicer it would’ve been to just write the component declaratively in JavaScript.
Not to poo-poo on templating/HTML preprocessing. I write “components” in Twig every day as part of my job, and for the most part, it’s pretty awesome. But writing the initial state of a component, accounting for props, and then using traditional imperative DOM manipulation to handle state changes from there is exactly the messy pain point that I think is referred to when the sentiment of “Jekyll (et al.) doesn’t do components” is expressed.
If all you need is stateless components, great. But really it’s statefulness that’s the fulcrum of the conversation.
I do agree that “component” is more of a term referring to a way of thinking about the design/architecture of pieces of a project. But if it’s stateless, the actual file you’re passing around is simply a template. The word “component” refers to the way of thinking and the actual file you write once you introduce statefulness, in my opinion. Again, not to be gatekeepy; I really like doing component-based design in Twig. But there’s usefulness in the distinction.
Part of me thinks, well, if those little bits then became Web Components, then we get the interactivity bits too. And soon we’ll be able to @scope the styles, and more and more we get what we really want from “components”.