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 帖子的評論中對會議進行總結。