我喜欢 Katie Kodes 这里给出的反驳。 我以前说过，我认为服务器端语言还没有像 JavaScript 那样很好地实现“组件构建”，但嘿，这是一个很好的观点。
1. 任何用 JSX 在文件中定义的基本 HTML 片段“组件”，然后作为
<MyComponent key="value" />进行交叉引用，您也可以轻松地用 Liquid 在文件中定义，并在 Jekyll 中作为{% include MyComponent.html key=value %}进行交叉引用。2. 任何用 JSX 在文件中定义的基本 HTML 片段“布局”，然后作为
<MyLayout>Hello, world</MyLayout>进行交叉引用，您也可以轻松地用 Liquid 在文件中定义，然后在 Jekyll 模板的前端 matter 中作为layout: MyLayout进行交叉引用。
任何 具有局部变量的偏置功能的 HTML 预处理器 都非常接近于复制无状态 JavaScript 组件的最佳功能。 这条线在使用诸如 Eleventy Serverless 之类的东西时变得更加模糊，这些东西可以通过访问云函数的 URL 来动态构建单个页面。
但问题是“无状态”。 一旦您需要一些 JavaScript 在某些事件后更改组件的状态，您就会意识到用 JavaScript 声明式地编写组件会多么好。
不要贬低模板/HTML 预处理。 我每天在工作中都会使用 Twig 编写“组件”，而且大多数情况下它都非常棒。 但是编写组件的初始状态，考虑 props，然后使用传统的命令式 DOM 操作从那里处理状态更改正是我觉得人们说“Jekyll（等）不支持组件”时提到的混乱痛苦点。
如果您只需要无状态组件，那就太好了。 但真正重要的是 *有状态性*。
我同意“组件”更像是一个术语，指的是一种思考项目各部分设计/架构的方式。 但是如果它是无状态的，那么您传递的实际文件只是一个模板。 我认为，“组件”这个词指的是思考方式 *以及* 引入有状态性后编写的实际文件。 我再说一次，不是要设置门槛； 我真的很喜欢在 Twig 中进行基于组件的设计。 但是这种区别是有用处的。
我的一部分想法是，如果这些小片段变成了 Web Components，那么我们也会得到交互性。 很快我们就可以 @scope 样式，并且越来越接近我们从“组件”中真正想要的东西。