我看到 VuePress 刚刚 发布了 1.0 版本。简单来说,它是一个基于 Vue 的 静态网站生成器。但当然,您使用的是 Vue,这意味着您使用的是组件。
所有现代 JavaScript 框架都是基于组件的。即使它们在某些具体方面存在分歧(例如 Svelte需要编译),但它们似乎都同意使用组件的模型。React 全都使用组件。一个流行的 React 静态网站生成器是 Next.js。Vue 版本的则是 Nuxt.js。
然后还有 Gatsby,它完全基于 React。(请收听 我们最新的 ShopTalk Show,我们将讨论它。)Gridsome 似乎是在 Vue 世界中与之最相似的工具,其显著的比较点在于它们都旨在从任何来源获取数据。当然,它们也都是基于组件的。我不确定是否存在一个旗舰级的基于 Angular 的静态网站生成器,但它们确实存在,并且 Angular 的所有内容都归结为组件。
组件如此普遍,以至于您可能不再考虑它。但您可能会感受到它,特别是当您在非组件驱动的项目之间来回切换时。通常情况下,我认为 WordPress 开发并不是组件驱动的。当然,您有 header.php
和 footer.php
文件等等。您可以根据需要将它们拆分,但这有点临时性。您并不是明确地构建组件,并为这些组件提供本地数据并对其进行测试。(使用类似 Timber 的东西可以更接近这种方式。)
使用服务器端代码构建前端绝对没问题。服务器端渲染有很多优势。**但是,服务器端语言似乎并没有像 JavaScript 那样拥抱组件。**而且,由于每个人似乎都喜欢组件(前端开发人员显然喜欢它,设计师也以这种方式思考,后端开发人员也理解它……),因此我毫不惊讶地看到这些备受喜爱的项目从 JavaScript 中构建服务器端(或构建时)生成的网站,仅仅因为它基于组件,而组件就是一个好主意。
NuxtJs 才是第一名!
“但是,服务器端语言似乎并没有像 JavaScript 那样拥抱组件”
React 和 Angularjs 的想法来自 Java 的 JSF 和 Spring 以及 .NET 的 ASP MVC。这些框架迫使用户以组件的方式思考和工作。
这很酷!仅仅出于好奇,是否有关于那些早期日子以及想法来源的文章或其他什么东西?我相信血统甚至更深……现在真的没有新想法了,对吧? :)
但尽管有起源,我仍然觉得我关于服务器端语言没有以相同方式拥抱组件的陈述有一定的道理,至少在我所处的圈子里是这样。顺便说一句,Java 和 .NET 开发完全不在我的圈子里。我更接近于听到 Ruby、Python 和 PHP 开发人员在说什么,而且那里似乎并没有关于绝对强制组件组合的框架的讨论。
同意,JavaScript 世界正在从服务器端框架借鉴这个想法,这些框架非常重视组件的概念。
ASP.NET 最初使用“用户控件”,现在在 ASP.NET MVC 中使用“视图组件”。这些是自包含的组件,可以拥有自己的控制器和状态(就像 React 中的“类组件”)。还有“部分视图”,相当于 React 中的“函数组件”。
服务器端语言一直都有这些。事实上,早期的组件库工具就诞生于 Ruby on Rails 和 Django。Storybook 沿着同样的道路为 JavaScript 前进,但实际上它并不是什么新东西。
天哪,我记得早期的 SSI(服务器端包含)……这可以被认为是基于 HTML 的组件技术吗?
这是一个关于 ASP.NET 用户控件的好例子。您可以看到封装组件及其自身业务逻辑的出现,这些组件可以放置在页面的任何位置。您还可以看到传递属性到其中的语法的开始。在开始构建页面时,将 UI 分解成“用户控件”是很正常的,就像我们现在使用“组件”一样。
https://www.codemag.com/Article/0209031/ASP.NET-Extending-the-Power-of-Web-Pages-with-User-Controls
此模型催生了整个现成的自包含 UI 组件行业,这些组件可以组合成项目 UI,例如 https://demos.telerik.com/aspnet-ajax/。早期的例子确实是用户控件(带属性的组件)和一些全局 CSS/JS。
Rails 和其他 MVC 风格的框架具有构建由一系列 HTML 部分组成的 UI 的强大约定。将页面视图视为“容器组件”,而更小的视图则是传递参数(属性)以呈现组件的简单“函数组件”。当然,它们并没有强制执行该模型,但 Rails 具有非常强大的命名约定,只要您正确命名部分 HTML 文件(组件),它就会在您尝试呈现对象时找到它们。
<%= @order %>
的语法与<Order />
并没有太大区别——只是将值传递到返回 HTML 的事物的不同方式。