WordPress 核心 JavaScript 框架选择讨论继续开源社区领袖的意见
已发表: 2017-09-27
WordPress 的#core-js Slack 频道今天上午主持了一场由 Andrew Duthie 领导的热闹而富有成效的会议。 讨论较少关注具体的框架比较，而更多地关注框架在为 WordPress 构建 JavaScript 驱动的界面中将扮演的角色。 来自 React 和 Vue 社区的核心开发人员和领导者、Chrome 工程师以及 WordPress 社区以外的其他相关方加入了贡献者的行列。
“这次聊天将主要集中在确定构建核心功能的需求，与插件和主题作者的重叠，以及减少框架锁定的模式，”Duthie 说。 “理想情况下，这比简单地在真空中辩论特定框架的优点更高层次，并且应该被视为项目之间合作的机会，为 WordPress 开辟一条前进的道路，这将为未来的流失提供灵活性和弹性。”
Duthie 首先询问框架应该在 WordPress 开发人员的工作流程中扮演什么角色，并要求框架贡献者就可扩展接口的建议提供他们的观点。 这个问题让与会者有机会就 Web 组件的支持、Gutenberg 的与框架无关的块互操作性以及这可能如何影响 WordPress 的插件生态系统等主题进行权衡。
Gutenberg 工程师 Matias Ventura 说：“我有点不同意这样的想法，即无论核心（在本例中为 Gutenberg）用于支持构建有状态应用程序的一些复杂性，都将成为插件开发的事实上的标准。” “总的来说，这里的实际框架将是 WordPress 公开的内容和 API。”
使用与框架无关的方法来构建 Gutenblocks，核心决定构建的库不必成为插件开发人员的事实上的标准，但 Gutenberg 团队之外的许多人认为它在实践中将不可避免地以这种方式结束。 整个工程师团队都在等待这个决定，他们致力于采用 WordPress 押注的任何框架。
“为了提供一些关于 WP 对框架的决定如何影响下游开发人员的观点，我是波士顿大学的一名开发人员，我们的计划是专注于 WP 决定的任何框架，即使 Gutenberg 有一个完全不可知的 API，”Adam Pieniazek 说. “我们主要是一家 WP 商店（大约 1,000 个站点 WP 安装为我们的大多数/很多公共网络存在提供动力）并最终在 WP 之上创建了巨大的定制，这通常需要深入核心以查看后台实际发生的情况. 我个人比 React 更喜欢 Vue，但是如果 WP 决定使用 React，BU 将专注于在 React 中建立专业知识，以便我们需要在 API 之外进行查看/调试。 这并不意味着我们也不会使用 Vue，但它不会是我们的主要关注点。”
Pieniazek 的反馈与 Gravity Forms 联合创始人 Carl Hancock 的反馈相呼应，后者表示他的团队已准备好采用 WordPress 选择的任何库。
“尽管彩虹和蝴蝶有些人声称它与创建抽象层有关，因此人们最终会在大多数情况下采用任何核心用途，以便插件/主题开发人员可以使用他们想要的任何东西，”汉考克在 #core-本周早些时候的 js 频道。
来自 WordPress 社区之外的许多参与者似乎都同意与框架无关的方法，并且没有人渴望将单一框架强加给所有使用 WordPress 的开发人员。 剩下的问题是这实际上是如何工作的，以及它是否使开发人员处于在框架之上使用框架的困惑位置。
“由于 Gutenberg 本身将成为一个构建平台，最好的分离水平是框架用于构建核心，但不作为 API 暴露给块构建器，”AMP 工程师 Paul Bakaus 说。 “这让人们可以选择在必要时更换底层基础。”
Gutenberg 工程师 Riad Benguella 总结了团队一直在讨论的方法：
我认为我们尝试交流的内容类似于：
– WordPress Core 将在内部使用这个 X 框架
– 如果您想使用它，我们认为它很好
– 如果你想使用其他东西，你可以像使用 Core 选择的框架一样容易
Benguella 还表示，Gutenberg 的目标之一是“为我们将来如何扩展 WordPress 的 UI 奠定基础。” 一旦发布，团队可能会将目光投向 wp-admin 的其他部分并以相同的方式构建它们。
“如果 WP 的 UI 的所有部分都可以通过标准接口进行扩展，无论是简单的‘数据向下，事件向上’API，还是期待一个 WC，我认为这将明确区分‘使用什么框架作为核心' vs. '使用什么框架进行扩展开发，'”Vue.js 的创建者 Evan You 说。
当被问及他对 React 成为 WordPress 主要框架的看法时，React 维护者 Dan Abromov 犹豫是否支持 WordPress 采用该库。 他的回应强调了采用与框架无关的方法来扩展 Gutenberg 和未来 WP 界面大修的必要性。
“我真的不太了解 WordPress，所以我很难说它是否非常适合用例，”Abramov 说。 “通常我们将 React 用于高度交互的 UI，并发现它可以很好地适应应用程序的大小。 我也很乐意回答有关它的技术问题。 但我认为，一般来说，人们对模板与表现力有着强烈的看法，我不觉得将 React 强加于每个人是最好的方法。”
“我也有同样的感觉，”埃文尤说。 “对每个人强加一个单一的框架，不管是哪一个，IMO 都不是一个好主意，因为这势必会疏远那些不属于该框架的开发人员，并带来更大的长期稳定性风险。”
阿布拉莫夫还表示，人们对于选择框架的主题已经“非常痛苦和分裂”。 他还在会前发布了类似的观点。
当我阅读讨论主题（例如关于 WordPress）时，会感觉到人们认为每个团队都对其他团队怀有敌意。 那是假的。
— 丹 (@dan_abramov) 2017 年 9 月 26 日
把它想象成照看花园。 欢迎您来我们这里闲逛。 其他花园也很棒
— 丹 (@dan_abramov) 2017 年 9 月 26 日
“我认为区分'哪个框架用于核心'和'哪个框架社区开发人员用于扩展'很重要（并且在技术上是可行的），”Evan You 说。
“是的，我认为这里的目标是对我们向插件作者公开的内容不加干涉，只要我们公开的 API/接口足够灵活（并且容易）来构建他们需要实现的 UI 和交互， ”安德鲁·杜西说。
支持 Gutenblocks 的 Web 组件互操作性的主题也是会议期间讨论的一部分。
“虽然在这一点上不如大多数实际框架强大，但它们很可能成为 W3C 标准，确保它们会继续存在并不断发展，”Felix Arntz 说。 “此外，一旦浏览器完全支持，通过构建在上面的实际框架实现的功能就会减少。”
Polymer.js 代表 Justin Fagnani 表示他不同意它们“不那么强大”，并指出 Web 组件已经是 W3C 标准。
EventEspresso 核心开发人员 Darren Ethier 说：“我认为 WP 也具有独特的优势，可以帮助推动对本地 Web 组件的支持。” “现在几乎所有的框架都能够使用 Web 组件规范。 这只是正确实施的问题。”
一些参与者引用了 custom-elements-everywhere.com，该网站展示了流行的 JS 框架在以促进互操作性的方式交流自定义元素方面的进展。 Matias Ventura 询问 React 和 Vue 核心开发人员目前 Web 组件（及其未来）如何适应每个框架。
“在 React 中，我们有一些 Web 组件支持，但并没有把它作为优先事项，因为过去用例似乎很少，特别是因为添加 Web 组件在您的第一方应用程序中没有多大意义控制整个堆栈——但我们确实为它们提供了一些支持，我很高兴现在或将来添加更多，”Sophie Alpert 说。
“在高层次上，我认为像 React/Vue 这样的框架提供了 Web 组件中没有真正解决的问题：响应状态变化的高效和声明性 DOM 更新，”Evan You 说。 “这也是聚合物存在于 WC 之上的原因。 我一直承认 WC 作为互操作接口的价值。”
总体而言，与会人员相互尊重、协作并渴望贡献他们的专业知识，以帮助 WordPress 贡献者在框架选择过程中找到最佳前进方式。 讨论将在下周的会议上继续进行，并可能在即将发布的 Make/Core 帖子的评论中对会议进行总结。