用塊而不是塊來思考的含義

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 是什麼，它代表什麼。