用块而不是块来思考的含义

Gutenberg 是一个基于 JavaScript 的编辑器（更具体地说，它是一个基于 React 的编辑器），它将很快改变为 WordPress 创建内容的体验以及（在即将到来的阶段，当 Gutenberg 转变为站点构建器时）创建体验WordPress 网站。

网站建设者古腾堡将要求以不同的方式思考如何奠定网站的基础。 在我们已经可以称之为“旧”模型的情况下，WordPress 网站是通过模板（ header.php 、 index.php 、 sidebar.php 、 footer.php ）提供结构并从单个 blob 获取页面上的内容来创建的HTML 代码。 在新模型中，页面有 (React) 组件放置在整个页面上，每个组件都控制自己的逻辑、加载自己的数据和自渲染。

为了从视觉上欣赏即将到来的变化，WordPress 正在从这个开始：

……对此：

我相信从 HTML 代码块切换到构建站点的组件无异于一种范式转变。 Gutenberg 的影响远不止从 PHP 到 JavaScript 的转变：过去可以做的事情可能不再有意义。 同样，一个充满可能性的新世界打开了，例如丰富而强大的用户交互。 Web 开发人员不会从用一种语言创建网站转变为用另一种语言创建网站，因为网站将不再相同； 这将是一个完全不同的站点。

推荐阅读：古腾堡 WordPress 编辑器的完整剖析

出于多种原因，古腾堡尚未完全被 WordPress 社区所接受。 一方面，新架构基于大量工具和技术（React、NPM、Webpack、Redux 等），这比旧的基于 PHP 的架构更难学习和掌握。 虽然可能值得学习提供新功能的新堆栈，但并非每个妈妈和流行网站都需要这些新的、闪亮的功能。

毕竟，全球 30% 的网站都是 WordPress 网站并非巧合：其中大部分都是非常简单的网站，例如博客，而不是动态的社交网络，例如 Facebook。 另一方面，WordPress 的包容性意味着任何人都可以建立一个简单的网站——即使是没有编码经验的人，例如设计师、内容营销人员和博主。

但是新架构的复杂性会让很多人望而却步（我什至不想考虑用缩小的 JavaScript 代码调试我的网站）。 另一方面，一旦 Gutenberg 上线，Facebook 支持的 React 将在一夜之间被添加到全球多达 30% 的网站中。 许多人对赋予任何类型的 JavaScript 库如此强大的功能感到不舒服，而其他许多人则不信任 Facebook。 为了缓解这种担忧，Gutenberg 将 React 抽象为也可以在其他框架或库中进行编码； 然而，在实践中，React 无疑将成为主要的 JavaScript 库。

然而，被提供一个充满可能性的新世界的前景确实是美好的。 就我而言，我很兴奋。 然而，我兴奋的不是技术（React）或实现（Gutenberg），而是概念，即使用组件作为构建单元创建站点。 将来，实现可能会切换到另一个平台，例如 Vue，但这个概念将保持不变。

预见我们将能够实现哪些新功能并不总是那么容易。 适应新范式需要时间，我们倾向于以旧方式使用新工具，直到我们明白如何使用新工具来实现新目标。 即使是 PDF 文件（它是印刷的代表，是网络诞生之前的主要技术）仍然是网络上的常见景象，忽略了网络相对于印刷的优势。

“在电脑屏幕上模仿纸，就像撕下 747 的机翼，将其用作高速公路上的公共汽车。”

— 特德·尼尔森

在本文中，我将分析通过基于组件的架构（作为概念）和通过 Gutenberg（作为实现）构建站点的几个含义，包括它可以提供哪些新功能，它可以与当前的网站开发集成多少趋势，以及它对 WordPress 的未来意味着什么。

扩展内容的多功能性和可用性

将所有内容视为块的一个非常重要的副作用是它允许单独定位 HTML 块并将它们用于不同的输出。 而插入到 HTML blob 中的内容只能通过网页访问，作为块可以通过 API 访问，并且它的元数据很容易获得。 以媒体元素为例——例如视频、音频或图像。 作为一个独立的块，视频可以在应用程序中播放，音频可以作为播客播放，图像可以在发送摘要时附加到电子邮件中——所有这些都无需解析 HTML 代码。

同样，块中的内容可以适应不同的媒体：从最小的屏幕到最大的屏幕、触摸屏或桌面、通过语音或触摸控制、2D/AR/VR，或者谁知道未来会发生什么。 例如，音频块允许在 Apple Watch 上播放音频，通过车载系统或 AWS Echo 进行语音命令，或者在使用 VR 耳机时作为虚拟世界中的浮动项目。 块还可以更轻松地为要在不同输出中发布的内容设置单一事实来源，例如响应式网站、AMP、移动应用程序、电子邮件或任何其他输出，正如 NPR 通过他们的 Create Once 所做的那样, Publish Everywhere (COPE) 方法。

注意：有关这些主题的更多信息，我建议观看 Karen McGrane 在 Zombie Apocalypse 演讲中的内容。

块也可以改善用户体验。 如果通过 3G 浏览网站，块可以在慢速连接模式下自渲染以显示低质量图像并跳过加载视频。 或者它可以增强布局，例如在网页的任何位置单击即可显示图片库，而不仅仅是在文章中嵌入的位置。

这些体验可以通过内容与形式的分离来获得，这意味着内容的表现和意义是解耦的，只有意义保存在数据库中，使表现数据成为次要并保存在另一个地方。 语义 HTML 是这个概念的一种表达：我们应该始终使用表示含义的<em> ，而不是表示形式的<i> （使字符以斜体显示），因为这样该内容将可用于其他媒体，例如语音（Alexa 无法阅读斜体字，但她可以在句子中添加重点）。

将内容与表单彻底分离是非常困难的，因为演示代码通常会通过 HTML 标记添加到块内（添加类“pull-right”已经意味着演示）。 但是，使用块构建站点已经有助于在布局级别实现某种程度的分离。 此外，为只做一件事而创建的块，并且做得很好，可以利用适当的语义 HTML，在其自己的架构中对 HTML、JS 和 CSS 有很好的关注点分离（以便将它们移植到其他平台可能只需要最小的努力，）并且至少在组件级别是可访问的。

注意：一般的经验法则：一个组件的包容性越强，它就越能为尚未发明的媒介做好准备。

不幸的是，Gutenberg 在设计时并没有考虑到这个目的，因此块也包含大量用于演示的 HTML 标记。 例如，来自外部图像的图像块的含义只有图像的 URL、alt 描述和标题（可能还有宽度和高度）； 创建图像块后，将以下代码块保存在数据库中（类aligncenter用于演示，如果仅存储含义，标记<div class="wp-block-image" />将完全多余）：

 <!-- wp:image {"align":"center"} --> <div class="wp-block-image"> <figure class="aligncenter"> <img src="https://cldup.com/cXyG__fTLN.jpg" alt="Beautiful landscape"/> <figcaption>If your theme supports it, you'll see the "wide" button on the image toolbar. Give it a try.</figcaption> </figure> </div> <!-- /wp:image -->

此外，块保存在帖子的内容（这是一个大的 HTML blob）中，而不是每个块在数据库中都有自己的条目。 可重用块（也称为全局块）确实有自己的条目，这让我担心开发人员可能会将标准块转换为可重用块，只是为了快速破解以直接在数据库中访问它们。

同样，我担心如果设计不当，区块甚至会对我们的网站造成严重破坏。 例如，不知情的开发人员可能会忽略最小功率规则，将 JavaScript 不仅用于功能，还用于 CSS 和标记。 此外，Gutenberg 的服务器端渲染 (SSR) 功能不是同构的（即它不允许单个代码库为客户端和服务器端代码生成输出），因此动态块必须实现生成 HTML 代码的功能也像 PHP 一样提供渐进式增强（没有它，网站在最初加载时是无法访问的）。

总而言之，块是朝着使 WordPress 内容在任何格​​式和任何媒体上可用的正确方向迈出的一步，但它们不是一个最终的解决方案，所以仍然需要做很多工作。

表现

性能很重要。 更快的网站会带来更快乐的用户，从而带来更好的转化率。 例如，Etsy 的团队上架了尽可能酷的新功能，如果这些功能使他们的网站加载时间超过临界阈值（我建议观看 Allison McKnight 关于长期建设性能的演讲和幻灯片），同时Twitter 的团队几年前重新设计了他们的网站，以支持服务器端渲染，以便尽快显示内容，并不断实施大量小改动，以提供快速的用户体验。

JavaScript 对开发人员如此有吸引力，他们对使用它没有任何限制，这是一个真正的问题：JavaScript 在性能方面非常昂贵，应该非常小心地使用它。

就目前而言，Gutenberg 远非最佳：虽然使用旧编辑器（我们需要安装经典编辑器）创建帖子需要加载大约 1.4 MB 的 JavaScript，但 Gutenberg 加载大约 3.5 MB 的 JavaScript，只是为了它的基本经验（即不安装任何附加块）：

这意味着，就目前而言，3.5 MB 是基准，随着站点管理员安装更多块，加载大小只会从那里增加。 正如最近在 Smashing Magazine 上的一篇文章中所看到的，创建一个推荐块需要 150KB 的压缩 JavaScript。 一个标准站点需要多少块？ 一般网站需要下载多少 MB 的 JavaScript？

影响是多方面的：一方面，下一个十亿用户无法访问一个繁重的网站，这些用户主要通过慢速连接访问，并且他们购买的数据计划占其工资的很大一部分。 对他们来说，每 MB 的数据都会有所不同：发送 Whatsapp 消息是负担得起的，而下载几 MB 的脚本只是为了加载一个站点则不是。

确实，网站的用户不需要与 Gutenberg 交互，因为 Gutenberg 只是为了构建网站，而不是为了使用它：Gutenberg 是后端编辑器，而不是前端编辑器（它可能永远不会是——至少作为 WordPress 核心的一部分）。 然而，内容创作者将受到惩罚，他们已经是一个相当大的目标。 此外（正如我之前所说的），用户最终也可能会受到动态块的惩罚，动态块可能会通过客户端 JavaScript 而不是服务器端 PHP 创建他们的标记。

还存在由 3rd 方插件添加的重复功能导致的膨胀问题。 在过去，一个 WordPress 网站可能会加载多个版本的 jQuery，这相对容易修复。 如今，有大量的开源库可供选择以实现所需的功能（拖放、日历、多选组件、轮播等），因此更有可能是一个具有数十个 3rd 方块的站点将具有由不同库实现的相同功能，从而造成不必要的膨胀。 此外，Gutenberg 本身还有一些臃肿之处：因为块是在前端注册的，所以通过加载额外的脚本来取消注册已经注册的块。 在我看来，这是 Gutenberg 贡献者面临的最大挑战之一：建立一个简化的流程，允许任何人（不仅仅是有 Webpack 经验的开发人员）删除不需要的库并仅打包应用程序所需的最少资源集.

最后，我再次提到 Gutenberg 支持服务器端渲染，但由于它可能不容易维护，开发人员可能会倾向于不依赖它。 在这种情况下，从 REST 端点获取数据需要额外的往返成本，只是为了呈现布局，在此期间用户将等待。

在我看来，性能将是 Gutenberg 面临的主要挑战之一，它在广泛采用方面可能成败，还有很多工作要做，主要针对 Gutenberg 成为网站的下一阶段建设者。

网络标准

如前所述，Gutenberg 对 React 进行了抽象，以提供一种与框架无关的构建块的方法，如果实施得当，可以避免 WordPress 被锁定到 React。 WordPress 社区在将任何 JavaScript 框架合并到 WordPress 核心时都很谨慎，这在很大程度上是因为 Backbone.js 在被添加到 WordPress 核心后不久，人气急剧下降，而且除了为媒体管理器提供动力之外，并没有完成很多功能用它。 即使 React 是目前最流行的 JavaScript 库，也没有理由相信情况会一直如此（正如 jQuery 的解体可以证明的那样），并且 WordPress 必须为那一天终于到来做好准备（考虑到快速技术的步伐，可能比预期的要快）。

避免被任何库锁定的最好方法是通过 Web 标准，更具体地说，在这种情况下，通过 Web 组件实现块。 Web 组件是与浏览器 API 一起操作的强封装组件，因此它们不需要任何 JavaScript 库即可使用。 但是，它们可以通过任何客户端 JavaScript 框架来实现。

尽管 React 还没有提供与 Web 组件的无缝集成，但它最终（或者更确切地说是希望）会。 正如 React 的文档中所解释的，Web 组件和 React 组件可以一起工作：

“React 和 Web 组件旨在解决不同的问题。 Web Components 为可重用组件提供了强大的封装，而 React 提供了一个声明性库，可以使 DOM 与您的数据保持同步。 这两个目标是互补的。 作为开发人员，您可以自由地在 Web 组件中使用 React，或在 React 中使用 Web 组件，或两者兼而有之。”

到今天为止，这种情况发生的前景看起来并不乐观：我还没有找到任何使用 Web 组件构建块的教程。 我相信社区应该把精力集中在这个事业上，鼓励开发人员开始使用 Web 组件构建块，而且越早越好，因为 Gutenberg 强迫我们现在就学习新技术。 这是一个从一开始就为 Web 标准奠定坚实基础的机会。

站点之间的互操作性，站点的同质化

区块是比主题或插件更小的实体，因此最终区块将可以自行访问，并通过新创建的区块市场获得。 由于生态系统中的许多参与者急于成为第一个推销其解决方案的人，因此很可能最初会出现寒武纪区块爆炸式增长，从而在中长期将最成功的解决方案合并。

一旦尘埃落定，少数区块将脱颖而出并成为赢家，在其特定类别中获得大部分市场。 如果/何时发生这种情况将引起关注和欢呼：担心新一轮网络同质化浪潮正在发生（就像 Bootstrap 发生的那样），因为使用相同组件的网站最终可能具有相同的外观和感觉，对依赖相同组件和相同 API 的站点之间的互操作性提高感到高兴，这可以打开通往新机遇的大门。

我对扩展站点之间的互操作性感到特别兴奋。 从长远来看，这是一个可以撤销 Facebook 等王国的领域：与其依赖垄断网关来共享信息，不同社区的站点可以轻松地直接在它们之间共享数据。 这不是一个新概念：IndieWeb 运动长期以来一直致力于让任何人都可以在自己的服务器上拥有自己的数据，方法是让网站通过微格式相互交流。 例如，他们的 Webmention 网络标准允许两个站点进行对话，其中每个评论和响应都存储在两个站点中，而 Micro.blog 提供了一种 Twitter 类型但基于开放网络，其中帖子用户时间线上的信息来自订阅网站的 RSS 和 JSON 提要。 这些努力很棒，但影响仍然很小，因为参与其中需要一定程度的技术知识。 Gutenberg 的基于组件的架构可能会产生更广泛的影响：流行的块可以使许多 WordPress 站点相互通信，最终允许网络上多达 30% 的站点成为去中心化、松散耦合网络的一部分.

不过，在可行之前，该领域需要大量工作。 我不认为默认的 REST 端点是最好的通信接口，因为它们不是为此目的而设计的（来自 micro.blog 的人们通过他们的 JSON 接口提出了更好的解决方案，该接口基于 RSS 规范）。 此外，REST 本身正在被 GraphQL 淘汰，所以从长远来看，我不会对它寄予厚望。 我还参与寻找一种更好的方法，为此我目前正在研究一种不同类型的 API，它可以仅在一个请求中检索所有需要的数据，并通过基于组件的架构支持可扩展性。

我还希望与云服务的集成更加突出，因为提供商可以发布自己的块来与自己的服务进行交互。 因为组件是一个独立的单元，只需将​​块拖放到页面中，就可以从用户的角度完成所有工作，从而非常容易构建强大的网站，而无需了解或很少了解。 例如，像 Cloudinary 这样的图像存储提供商可以发布一个块，根据设备的视口自动裁剪图像，或者在支持的情况下将图像请求为 WebP，或其他用例。

综上所述，区块市场的整合可能会带来外观和感觉方式的同质化，这将是一个令人遗憾且应该避免的事件，以及在站点之间的互操作性和数据共享以及与云服务集成方面的强大能力。

与模式库集成

模式库是用户界面设计元素的集合，每个元素通常由 HTML、JS 和 CSS 片段组成。 块是一个自治组件，通常由一些 HTML、JS 和 CSS 组成。 因此，块显然非常适合用模式库记录/构建。 让块发布他们的模式库将是一件大事，因为它可以使团队不仅仅在站点级别开始实施站点的模式库，而是作为来自所有必需块的迷你模式库的聚合和细化。

我相信在这种情况下会发生类似于我之前提到的用于生成无膨胀 JavaScript 包的简化过程，但涉及 UI/UX/文档。 对于 Gutenberg 贡献者来说，建立一个流程，使块开发人员可以轻松地为他们的块创建模式库，这既是挑战也是机遇，当这些块聚合在一起时，可以为站点生成一个连贯的模式库。 实施得当，从文档/维护的角度来看，此类功能可以降低构建站点的成本。

WordPress会变成什么？

古腾堡肯定会让网站更具吸引力，尽管代价是并非每个人都能掌握所需的专业水平。 从长远来看，这可能会导致更高的质量，更低的数量。 来自“出版民主化”的 WordPress 格言，这可能会成为一个问题。

我对 Gutenberg 充满热情，但更多的是基于组件架构的概念，而不是基于 React 的实现。 总的来说，我同意 Matt Mullenweg 在 WordCamp Europe 2018 上所说的为古腾堡辩护的观点：

“现在为我们服务了 15 年的 WordPress 基础将不会持续到接下来的 15 年。”

但是，我也相信 15 年后的 WordPress 最终可能会与我们今天所知道的完全不同。 我想知道 WordPress 最终是否会主要成为基于客户端的编辑器，仅此而已：将 Gutenberg 集成到 Drupal 的倡议，旨在使 Gutenberg 成为开放网络的编辑器，将正式将 WordPress 正式化为无头 CMS 操作通过 REST 端点。 这本身就是一个很好的发展，但它会让 WordPress 成为后端可有可无：如果任何其他后端平台提供更好的功能，那么没有理由再坚持使用 WordPress 后端了。 毕竟，客户端 Gutenberg 将能够与它们中的任何一个一起工作，而使用 WordPress 创建站点的简单性将会丢失，从而与所有其他平台公平竞争。

特别是，如果开发人员觉得维护两个代码库（一个在 JavaScript 中，一个在 PHP 中）来渲染动态块过于繁重，并决定转向支持同构服务器端渲染的平台，我不会感到惊讶。 如果这种情况真的发生，Matt 会决定将 WordPress 后端转移到 Node.js 吗？

主要是因为这个问题，我敢说 15 年后的 WordPress 可能是一个与现在完全不同的实体。 谁知道会发生什么？

结论

通过使组件成为构建站点的新单元，Gutenberg 的引入将对 WordPress 进行转型。 与任何范式转变一样，会有赢家和输家。 不同的利益相关者会根据自己的情况将 Gutenberg 视为积极或消极的发展：虽然网站的质量会提高，但通过聘请能够处理其复杂性的开发人员来构建这样一个网站的价格也会上涨，这使得它变得更便宜并且不太受欢迎。

这是激动人心的时刻，也是关键时刻。 从现在开始，WordPress 可能会慢慢开始成为与我们习惯不同的实体，我们最终可能需要重新思考 WordPress 是什么，它代表什么。