狠狠色丁香婷婷综合尤物/久久精品综合一区二区三区/中国有色金属学报/国产日韩欧美在线观看 - 国产一区二区三区四区五区tv

作者 | Alex Russell   

編譯 | 屠敏、鄭麗媛

出品 | CSDN（ID：CSDNnews）

以下為譯文：

在過去的十年里，我的工作重點是與團隊合作，共同開發面向桌面和移動端的 Web 產品。這讓我有機會近距離接觸了各種各樣的團隊、產品和技術棧，回顧過往，我參與了超過 100 個項目。

雖然我個人更希望將大部分時間專注于改進 Web API，但往往事與愿違，與合作伙伴們的合作大多數時間都用于解決由“現代”前端框架（如 React、Angular 等）及其周圍文化所帶來的性能和可訪問性問題。這些問題在基于 React 的技術棧中尤為突出。

這令人不安，因為 React 已經被很多人視為是一門過時的技術，但它依然出現在新建的應用程序中。

不過，也有一些人仍然堅持認為 React 是“現代”的技術框架。也許在今天這篇文章里，我們可以通過理解“現代”一詞來解釋這種情況，就像它在藝術中應用一樣。React 和藝術作品一樣，并沒有展示當代的設計或構建技術。它們并非為了滿足當前的需求或性能標準而構建，而是基于過去的過時方法，并且在那個時代這些方法曾經是最先進的、最昂貴的。

為了讓更多的團隊遠離使用 React 帶來的后續困境，我基于最新的研究，分析當前的局勢，同時通過講座提醒管理者和開發人員注意當前前端正統觀念的危害。

簡而言之，在 2020 年代，不應該再有人基于 React 開始新的項目。這一點無須質疑。

客戶端復雜性最小化原則

在服務器上運行的代碼完全計算出成本。服務器端系統的性能和可用性由提供服務的組織控制，延遲性則可以由開發人員和運維工程師主動管理。

相比之下，運行在客戶端的代碼則是在“魔鬼的計算機”上運行。用戶所體驗到的延遲、客戶端資源，甚至可用的 API，都不在開發人員的控制范圍之內。

客戶端 Web 開發或許最好可以將其理解為一種面向影響力的編程方式。一旦代碼離開數據中心，Web 開發人員能做的只是祈禱和希望。

因此，一個出奇有效的策略是減少代碼量。實際上，這意味著開發者可以優先使用 HTML 和 CSS 而不是 JavaScript，因為 HTML 和 CSS 更加簡潔，并且在壓縮時能有效減小文件大小，同時也能優雅地在不同條件下降級工作。聲明式編程的方式能夠讓開發者通過發送較少的字節來實現更多的功能性界面（UI）。這些優化不僅能提高網站的穩定性（韌性），還能降低開發和維護成本，而這種效果隨著網站使用時間的增長會成倍放大。

基于 React、Angular 和其他一些遺留的、面向桌面的 JavaScript 框架的技術棧，通常采取的做法與上述的減少代碼量的策略相反。雖然這些生態系統口頭上承諾要防止不必要的客戶端代碼過多，但實際上，它們往往會通過 NPM 包的合并，導致代碼中包含了大量冗余的庫和代碼，比如 core-js、lodash、underscore、為已不存在的瀏覽器提供的 polyfill、用戶空間的 ECC 庫、moment.js以及其他一百個類似的復雜庫。這些冗余的代碼和庫不僅增加了文件的體積，還可能帶來不必要的性能負擔。

如今這種情況已經進入失控狀態，似乎 2024 年的 React 開發者在構建聊天機器人時，根本無法不包括那些 2010 年代的遺留庫，甚至還要再加上至少一個非常笨重的 MathML 或 TeX 格式化庫來顯示公式，事實上，這種需求只會在極少數會話中才會出現。

當前，公司的技術主管和經理們需要打破這種魔咒，深入了解自己所做的決策對客戶端性能、效率和用戶體驗的實際影響，承擔起更多關于客戶端技術決策的責任。實際上，這意味著在所有新的工作中禁止使用 React。

好吧，那又該怎么辦呢？

禁止使用 React 這個問題有兩種解讀觀點，值得仔細區分：

• 狹義形式：“假設我們確實需要客戶端渲染，你會推薦哪些具體技術來替代 React？”

• 廣義形式：“我們的產品棧已經選擇了 React，并且接受了那些在以 React 為中心的播客中討論的各種神話。你現在要求我們重新思考整個架構。我們該選擇哪種靈丹妙藥代替 React？”

那些做出正確產品決策的團隊，可以通過客觀的實驗對比，解決上述狹義上的問題。具體來說，團隊可以通過構建多個小規模的概念驗證（PoC）來測試不同方法的可擴展性和局限性。這種做法不僅有效，而且很有趣，因為它允許團隊在明確的約束條件下嘗試新技術或方法，從而改善最終的用戶體驗和結果。

注意：構建 SPA（單頁應用程序）或客戶端交互性模塊的開發者有很多選擇。這篇博客不會推薦具體的工具，但 Svelte、Lit、FAST、Solid、Qwik、Marko、HTMX、Vue、Stencil 等以及其他數十種當代框架都值得關注。

盡管它們的初始成本較低，任何投資這些框架的團隊仍然需要對客戶端負載和復雜度進行嚴格控制，因為 JavaScript 的成本至少比同等 HTML 和 CSS 高出 3 倍（按每字節計算）。

毋庸置疑，技術棧的決策標準會隨著時間的推移而發生變化。可能是因為上次審視技術棧時的條件發生了顯著的變化，或者是網站的用戶群體和產品經理、技術主管預期的用戶群體之間差距很大。因此，收集相關數據來了解這些變化，可以幫助團隊在做第一次決策時更快速地縮小選擇范圍，為后續的比較實驗提供更有針對性的依據。

但我們花最多時間接觸的團隊并不處于這種位置，也不會做上述這些事情。

很多人在問“如果不使用 React，那用什么？”時，認為自己是在問狹義的問題，但實際上他們正面臨廣義問題。令人震驚的是，很多（有能力、出于善意的）產品經理和工程師沒有深入思考架構的原因和背景，而是選擇跟隨潮流。

對于一些人來說，放棄 React 這種流行的技術框架，會讓他們感到迷茫，甚至懷疑自己是否還能理解這個世界。處于這種狀態的團隊，面臨的是關于技術選擇和價值觀的認知危機。他們不確認如何判斷自己的技術選擇是否優于其他選擇，也不知道為什么會選擇這個技術棧而不是另一個？

很多人需要幫助去找到更合適的方法來解決前端問題。如今，框架主義（即依賴使用框架來解決問題的思想）已成為前端開發的主流理念。持有框架主義的人認為，只要團隊足夠努力地使用某個框架，所有的用戶問題都會得到解決。然而，這是邏輯錯誤，甚至可以說是完全錯誤的。事實上，唯一能使 Web 體驗變得好的是關心用戶體驗——特別是邊緣用戶的體驗。技術來來去去，但始終能帶來差異的，是關心用戶。

通俗地說，這場斗爭最具挑戰性的地方在于說服經理和技術主管，讓他們從用戶需求出發。正如全球知名咨詢公司 Public Digital 所言，“為用戶需求設計，而非為組織便利設計。”

要做到這一點，需要改變思維方式——從單純依賴承諾和想象，轉向基于實際的研究和證據來做決策。這與所謂的“無所不用其極的工程”相吻合，因為工程的本質是利用已知條件和限制，為用戶和社會創造切實可行的解決方案。

與之相對的是一種不切實際的幻想——認為沒有約束條件，或者認為那些限制根本不適用于你的產品。這種想法用一個詞總結就是“胡扯”。

現實中，要拒絕根深蒂固的“胡扯”做法并非易事。所謂的“框架主義”宣揚，改善用戶體驗的方式是采用更多（或不同）的框架生態工具。乍一看，這讓信奉者有事可做，看起來像是在進行工程實踐，實際上并非如此。這種做法甚至讓人深信不疑，只關注框架生態內部的解決方案，而忽視框架之外更實際、更有效的選項。如果有一種非主流的方式對用戶更有幫助，“框架主義者”可能還會把它當成錯誤去排斥。更糟的是，如果沒人拿出數據和證據來反駁這些錯誤做法，就很難證明它們的問題。結果，忽視用戶需求的做法會越來越荒謬，而質疑這種做法的人反而可能被視為“異端”，甚至被打壓。

說白了，這一切都是“胡扯”。

現實主義的做法和框架主義正好相反。現實主義者不會沉迷于那些看似高深的概念，而是用數據和事實來評估用戶體驗。他們關心的是真實情況，而不是理想化的假象。

要打破框架主義的迷思，最有效的工具就是為管理層提供真實的、以用戶為中心的系統表現數據。比如，可以使用 RUM（真實用戶監測）工具，像 Core Web Vitals 來分析網頁性能；或者通過實驗室工具（比如 WPT）獲取具體的測試結果。同時，監測用戶的關鍵行為路徑，把這些數據和業務目標結合討論，也能更快推動改變。

像 RUM 和其他基準數據，能幫助團隊擺脫盲目追逐框架的陷阱。因為數據能清楚顯示：引入這些框架到底花了多少成本，實際能帶來多大的回報。只有用數據說話，才能讓團隊做出真正理性的決策，而不是盲目“信仰”某些框架。

沒有什么有價值的東西丟失

通過政策禁止 React（或其他類似框架）的使用，既是一個有效減少成本的策略，也可以幫助團隊把注意力轉向為用戶提供更有價值的產品。然而，要真正獲得更好的結果，僅僅限制某些框架是不夠的。必須徹底擺脫“框架主義”的影響，也就是避免盲目地依賴框架來做決策。如果只是避免了一種錯誤（比如過度依賴 React），卻把省下的資源浪費在其他類似的錯誤上（比如換用另一個框架但仍然不關注用戶需求），最終不會有任何真正的進步或收益。

針對上述廣義形式的問題，可以從以下幾個維度來做解答：

• 關注用戶：決策者必須接受，他們對自己工程選擇的結果負有直接責任。不能推卸責任。系統要么對用戶有效，包括那些邊緣用戶，要么就無效。性能不達標的系統必須被能夠提供性能的版本所替代。沒有什么是神圣不可侵犯的，只有可以通過適當應用約束來解決的問題。

• 證據：管理層與工程團隊之間的基本共識是對現實主義的承諾。更好的證據必須占上風。

• 護欄：必須制定明確的政策，防止一些框架主義者提出的“如何改善用戶體驗”的主觀假設和不切實際的說法。比如，英國政府數字服務部門要求所有服務必須使用漸進增強技術構建。這類政策可以根據需要進行靈活調整（例如，允許特殊情況下提交額外申請），但重要的是要設定一個基本的技術標準。通過將實際證據轉化為明確的政策，可以更有效地推動團隊關注真實用戶需求，而不是依賴沒有實際依據的主觀判斷。

• 比較實驗：沒有清晰的關鍵用戶路徑就不應該上線部署新系統。關鍵用戶路徑是用來描述用戶在系統中最常做的事情，一旦明確這些路徑，就可以通過實驗比較不同系統在真實環境下（尤其是面對邊緣用戶的特殊需求）表現如何。這一過程還凸顯了產品經理的職責：他們不僅需要提出各種可能的實驗（這些實驗通常效率低下），更重要的是，要定義清晰的產品定位，并明確什么樣的結果算是成功。這項工作可能會讓人感到壓力和不適，但這正是產品經理的核心任務。如果某位產品經理覺得自己無法勝任這種角色，那么讓從容地接受他們的辭職吧。

不同類型網站的最優選擇

為了說明現實主義（注重實際效果）和框架主義（迷信框架工具）在實際應用中的區別，以下提供了一些例子作為說明。回顧過去，我們通常選擇技術時，會根據應用程序處理的關鍵需求來決定，比如對數據的操作次數和用戶會話的持續時間。有些應用程序的特點是用戶需要長時間使用（會話時間長），同時需要在界面中頻繁地、逐步地更新信息。在這種情況下，本地化的數據模型（例如，將數據存儲在用戶設備中以便快速處理）有助于更高效地應用更新。然而，這種需求并不普遍，是一種特殊情況。

短時會話的網站不能承擔太多的前端 JS

只有在這些特殊情況下，SPA 架構才應當考慮。

并且，只有在確實需要單頁應用程序（SPA）架構時，才應該將那些專門用來支持本地數據模型樂觀更新的工具（如前端框架和狀態管理工具）納入網站的架構設計中。

選擇的關鍵不在于是否選擇 JavaScript 框架，而是是否應該考慮支持 SPA 的工具。

對于大多數網站，答案顯然是“否”。

以下是一些示例情況：

信息性網站

旨在提供信息的網站幾乎總是應該使用語義化的 HTML 構建，并根據需要加入漸進增強功能。

像 Hugo、Astro、11ty 和 Jekyll 這樣的靜態網站生成工具在許多情況下都能很好地工作。內容變化較頻繁的網站應該考慮使用“經典”的 CMS 工具或像 WordPress 這樣的工具來生成 HTML 和 CSS。

對于博客、營銷網站、公司主頁、公共信息網站這樣的應用，它們的核心需求通常是展示內容而非復雜的交互。因此，應盡量減少在客戶端運行的 JavaScript 代碼的數量和復雜性。這類網站不需要采用為支持 SPA（單頁應用程序）設計的框架，因為這些框架是為更復雜的交互場景準備的，而不是簡單的內容展示。

為什么語義化標記和可選的漸進增強是正確選擇？

信息性網站通常具有較短的會話時間，并且擁有由服務器管理的應用數據模型；也就是說，頁面上顯示的內容的真實來源總是由服務器管理和擁有。這意味著不需要客戶端的數據模型抽象或客戶端組件定義，這些可能需要從數據模型中進行更新。

注：許多信息性網站包含作為獨立子應用的生產力組件。像 WordPress 這樣的 CMS 由兩個不同的部分組成；一個低流量、高互動性的編輯器界面供文章作者使用，一個高流量、低互動性的閱讀者界面供讀者使用。漸進增強應考慮應用于兩者，但對于沒有長時間會話的讀者視圖來說，漸進增強是絕對必要的。

電子商務網站

電子商務網站應該使用服務器生成的語義化 HTML 和漸進增強來構建。

亞馬遜與其基于 React 的競爭對手之間存在著穩定而顯著的性能差距，表明 SPA 架構在電子商務應用中的表現非常糟糕。沃爾瑪超過 70% 的流量來自移動設備，這使得他們選擇 Next.js 的決定對業務來說尤其有問題。

有許多工具可用于支持這種架構。構建電子商務體驗的團隊應優先選擇默認不加載 JavaScript 的技術棧，并通過控制客戶端腳本來防止在關鍵業務指標上出現回退。

為什么漸進增強是正確的選擇？

電子商務網站的整體形式在過去 20 多年中一直保持穩定：

• 具有當前優惠和搜索功能的登陸頁面

• 允許篩選和比較產品的搜索結果頁面

• 顯示產品相關媒體、評分、評論和替代品推薦的產品詳情頁

• 購物車管理、結賬和賬戶管理頁面

在所有這些頁面類型中，將顯示一個普遍存在的登錄和購物車狀態小部件。這個小部件以及網站的標志，有時是唯一一致的元素。

從多年的經驗來看，電子商務網站的 UI 差異性較大，用戶停留時間也會因為購物行為的多樣性而變化。此外，像商品價格這樣的內容需要實時更新，因此將應用的狀態（比如購物車信息或庫存）存儲在服務器端更為合理。為了讓電子商務網站加載得更快，最好的方法是優化頁面的大小和加載速度。這包括積極使用緩存、優化圖像和減小頁面體積，確保頁面盡量輕量化。

媒體網站

媒體消費網站在用戶停留時間和內容更新頻率方面差異很大。對于大多數此類網站，推薦采用“漸進增強”的設計理念。也就是說，網站的基礎版本應該是簡單且易加載的，以確保核心內容對所有用戶都可用。隨后，可以根據功能需求，逐步增加復雜性，比如添加動態交互功能。

為什么漸進增強和島嶼模式可能是正確的選擇？

許多媒體消費網站的互動功能（如評論區、點贊按鈕、推薦列表等）可以被視為相對獨立的小功能模塊。這些模塊像“互動島嶼”一樣獨立運行，擁有自己的數據模型，可以使用 Web 組件技術開發，將其嵌入在一個更大的靜態頁面中。

何時 SPA 可能是合適的選擇？

當用戶瀏覽媒體內容且需要持續進行媒體播放（例如“迷你播放器”的 UI）時，上述的設計方法就不再適用。原因在于當前的 Web 平臺存在一個基本限制：當用戶切換頁面時，頁面內容（例如正在播放的媒體）無法保留。因此，如果網站需要支持這樣的功能（如播放不中斷），應該考慮使用 SPA 技術，但要注意限制客戶端 JavaScript 的大小，避免性能下降。

另一個考慮使用 SPA 的情況是離線播放。因為它需要用 Service Worker 來管理本地緩存的媒體文件，以及需要有與服務器同步數據的方法（例如更新緩存或驗證用戶權限）。

在這種情況下，輕量級的 SPA 框架可能是合適的，同時還可以使用像 Zero 或 Y.js 這樣的連接狀態彈性數據系統。

社交網站

社交媒體應用的特點是，用戶使用時間長短不一，而且通常涉及多媒體內容。很多社交平臺會用“無限滾動”的界面，讓用戶不斷加載新內容，同時還支持復雜的功能，比如編輯帖子。這些功能設計上有明顯的分界點，通常與用戶瀏覽的深度以及客戶端和服務器之間的數據處理方式有關。

為什么漸進增強可能是正確的選擇？

大多數社交媒體的使用場景就是用戶在服務器上的數據模型基礎上，進行一些簡單的操作，比如“點贊”帖子等。另外，用戶會間隔性地看到新的內容更新。這種模式很適合用一種“混合方法”來實現，比如類似于 Hotwire 或 HTMX 那樣的技術，把服務器和客戶端的功能結合起來。

SPA 何時可能是合適的選擇？

在社交媒體應用中，有些功能可能需要更復雜的交互方式，比如“深度互動區域”（或稱“島嶼”）、用于草稿帖子緩存的功能。這些部分與主頁面展示的內容不同，需求更復雜，可以看成應用的一部分。

如果需要支持離線功能，就需要把數據模型和用戶狀態的快照下載到客戶端。這需要結合構建主應用的可靠性來設計。團隊可以考慮基于 Service Worker 的多頁面應用（MPA），配合“流拼接”架構。這種架構主要通過 HTML 提供頁面，同時啟用離線優先的邏輯和同步功能。但要注意，離線支持會對架構產生很大影響，因此這個需求必須在項目開始時就明確。

注意：有些人認為必須用 SPA 工具和框架才能構建支持離線功能的漸進式 Web 應用（PWA），但實際上并非如此。PWA 也可以用“流拼接”架構來構建，通過 Service Worker 在客戶端實現類似服務器端模板化的效果。

隨著多頁面視圖無縫過渡技術的發展，MPA 架構的 PWA 已經可以在不依賴大型 JavaScript 包的情況下，實現不同用戶狀態之間的流暢切換。盡管框架社區可能需要幾年時間才能完全適應這些技術，但它們已經可以被應用，并且在基礎架構和漸進增強的場景中表現優秀。

生產力應用

面向文檔的生產力應用可能是最難以理清的類別，因為協作編輯、離線支持和輕量級（快速）“查看”模式，且需保持文檔完整性，都是通用的產品需求。

以優先級排序的數據存儲（例如電子郵件客戶端）可能非常適合使用 SPA 技術。但是否能帶來更好的用戶體驗，取決于用戶在會話中的操作深度以及初次加載的性能成本。如果處理不好，很容易失敗，正如之前的討論所提到的那樣。

類似地，各種編輯器應用由于需要頻繁修改數據，天然適合使用本地數據模型和 SPA 架構。然而，這類系統的復雜性往往會導致性能問題，成為長期挑戰。因此，開發這些應用的團隊需要提前制定性能保障措施，比如明確關鍵用戶操作路徑，并部署適當的監控工具。這有助于及時發現問題，避免出現嚴重的性能問題，讓用戶體驗受損。

為什么 SPA 可能是正確的選擇？

編輯器類應用通常會頻繁更新數據，比如每次按鍵或鼠標拖動時都會更新內容。通過采用“樂觀更新”的方式，可以讓用戶在編輯時享受到流暢的體驗：編輯的內容立即顯示，同時后臺異步通知服務器進行保存。

不過，團隊需要注意，編輯器應用有時也會被用作查看工具。如果前期加載的代碼包太大，無論是用來看內容還是用來編輯，都可能導致加載時間過長，用戶體驗變差。更麻煩的是，系統在加載頁面時往往無法區分用戶是只想查看內容，還是準備開始編輯。

要想在這種情況下取得成功，團隊需要非常嚴格地控制代碼包的模塊化、分階段加載和延遲加載策略。例如，僅在用戶確實需要編輯功能時才加載相關組件。反之，如果團隊缺乏對關鍵路徑資源變更的審批和管理，性能問題就會頻發，導致用戶體驗不佳。

其他應用類別

有些應用天生需要很強的互動性，或者需要訪問本地設備的硬件，或者處理一些 HTML 本身無法直接處理的媒體類型，比如 3D CAD 軟件、編程編輯器、游戲流媒體、網頁游戲、媒體編輯軟件和音樂創作工具等。這些應用的需求往往需要復雜的客戶端 JavaScript 界面，但即使是這些應用，也應該像做生產力工具一樣，經過嚴格的評估，考慮以下問題：

• 關鍵用戶操作的路徑是什么？ 

• 平均會話的深度有多大？

• 我們會跟蹤哪些指標來確保性能在可接受范圍內？

• 我們如何嚴格管理關鍵路徑的腳本和資源？

這些類型的應用在 Web 上是可以成功實現的，但需要非常小心謹慎。

?

“但是……”

許多管理者和技術負責人，一旦他們對框架主義（frameworkism）產生依賴，就不得不應對一系列由其他過度反應者（Over Reactors）所提出的看似合理、實則很容易被推翻的理由。仔細查看這些反對理由，你會發現：其中沒有一個是真正將用戶的實際體驗放在首位的。通過這種現象，往往就可以判斷出這些對話的本質是什么。

“……我們需要快速行動”

每當聽到這樣的說辭時，最好的回應就是一個反問：“要多快？”

因為那種“隨便用 NPM 把代碼東拼西湊”的開發模式，就算在價值 3000 美元的高端筆記本電腦上看似運行良好，也很快就會讓團隊陷入困境。這種思維模式的后果，從重大的可訪問性問題到足以損害品牌形象的低劣性能問題，這十年來幾乎每周都會出現在我的辦公桌上。

我可以明確告訴你，所有這些團隊和產品都有一個共同點：它們并沒有因此變得更快。一些你聽說過的或者你本周使用過的網站都曾向我們求助，我們也盡職盡責地提供了幫助。通常的解決方案是，花費數周甚至數月的時間來解開這些由 JavaScript 造成的棘手難題。這種補救工作確實能修復由 JavaScript 濫用導致的收入和可訪問性問題，但在此期間團隊的進展將完全停滯——他們只能亡羊補牢，匆忙添加代碼質量關卡、包大小控制及相關流程，以防止進一步的倒退。

這種必要、痛苦且昂貴的補救措施，通常發生在最糟糕的時候，且幾乎得不到支持，這主要歸因于 JavaScript 生態系統內的緘默文化（omerta）。被困于這種體系中的管理者逐漸意識到，他們倉促做出的決定并不容易調整。原本為了加速進度而引入的復雜且難以理解的工具，現在反而成為了團隊必須花大量時間去學習、深入了解并熟練操作的負擔。與此同時，新功能發布的速度也會顯著放緩。

顯然，這并不是管理者當初接受“我們需要快速行動”這個理由時所期望的結果。

如果我們按照字面意思理解這一主張，即假設某個團隊不會因此陷入困境，那么這句話隱含的想法大致是：現在沒有充足的時間把事情做到最好（所以用 React？），但以后會有時間返工。

然而，這種邏輯與“尋找產品市場契合點”的基本原則直接相悖。

與硅谷常見的觀念相反，找到產品需求的最佳方法是讓它盡可能廣泛地可用，然后再逐步優化用戶體驗。我曾合作過的團隊經常驚訝地發現，消除使用障礙不僅能開拓新的市場，還能在他們之前低估的其他地區提高利潤率和業務成果。

當然，如果你銷售的是奢侈品類型（即炫耀價值遠高于實用價值的商品），那么優先考慮其他因素而非可訪問性也無可厚非。但在幾乎所有其他類別中，產品質量的回報可以理解為產品定位的清晰度。當使用 React 作為權宜之計時，實際上就是暗示了一種低質量的體驗，而這種體驗會直接弱化你服務的核心增長邏輯。如果你的目標是規模化而非排他性，那么為微軟早已停止銷售的老式桌面瀏覽器構建功能，就絕對是一個戰略性錯誤。

“……但 Facebook 用它就有效”

可以肯定的是，你的產品不是 Facebook，你遇到的問題與 Facebook 在 2010 年代初遇到的問題可能也截然不同；即使相似，效仿 Facebook 的做法也可能是一個糟糕的選擇。

而且實際上，這些工具對 Facebook 本身都沒有起到多大作用。Facebook 只不過恰好在某些社交領域處于壟斷地位，因此可以“燒錢”。如果你的公司情況并非如此，那么最好不要過度依賴那些基于 Facebook 成功故事的決策邏輯。

“……可我們的團隊已經很熟悉 React 了”

React 開發者本質上就是 Web 開發者的一部分，他們需要在 CSS、HTML、JavaScript 和 DOM 這個生態系統中工作，這是不可避免的，但這也意味著 React 是技術棧中最容易被替換的一環。切換模板系統（JSX 本質上就是模板語言）是 Web 開發者三十多年來一直熟練掌握的事情，即便是那些精通 Rails 和 ERB 等特定框架的人，也能輕松適應 Django、Laravel、WordPress 或 11ty 等其他項目。當然，各個框架間確實存在差異，但所有 Web 開發者都是多面手，能夠在不同環境中游刃有余。

更重要的是，React的專業知識本身也并不具備特別高的價值。任何熟悉 React 那些復雜慣例的團隊，都能快速掌握 Preact、Stencil、Svelte、Lit、FAST、Qwik 等眾多更快、更小、更高效的客戶端響應式系統，且這些系統對開發者的認知負擔要求更低。

“……這樣也方便招聘”

最近，科技行業發生了大規模裁員，我所認識的許多才華橫溢、富有同理心、以用戶為中心的工程師都無緣無故地被解雇了，僅僅因為他們的管理層未能預見疫情后市場的回歸正常波動。也就是說，現在人才市場上正在進行一場“大甩賣”，你可以根據需要提出任何技能要求，并且仍能找到非常合適的人選。

如果你招聘不到那些了解 Web 標準和基本原理的人才，請聯系我，我可以親自幫你制定招聘建議、職位描述、錄用標準及晉升指南，以便你能正確地重視這些人才：將他們視為被低估的英雄，他們將以極低的成本下為你的產品創造巨大價值，而無需花費巨資去解決 React 社區終于承認由框架主義（frameworkism）本身所導致的下一個問題。

簡歷不是生死契約

即使你決定在面試過程中篩選具備 React 經驗的候選人，這也并不意味著你應該使用 React。任何能夠駕馭復雜構建工具、TypeScript 特性和 JSX 語法變體帶來的各種細微問題的人，都完全有能力適應其他技術體系。

事實上，他們已經在不斷變化的流行技術漩渦中工作了。技術的快速迭代是真實存在的，這意味著問題不在于“這些人能否迅速上手？”（答案必然是否定的，無論如何他們都需要花幾周時間來熟悉你的特定環境），而在于“在我們的團隊生命周期中，哪種技術能提供最高的投資回報率？”

鑒于 React 及其他框架主義方案的高昂成本，在項目生命周期中，選擇當下流行的框架并不會比選擇成熟穩定的技術棧更有利。因此在長期來看，選擇那些穩定、可靠且易于維護的技術通常會帶來更高的回報。

關于“編程訓練營”

聽到管理者貶低那些從編程訓練營畢業的工程師，我就感到惡心，而這種現象似乎越來越常見。他們覺得：那些從編程培訓營出來的人——只是花錢學習課程大綱上內容的人——沒有能力或不愿意學習其他技術棧，這簡直是無稽之談。

編程訓練營的畢業生可能是初級開發者，他們對框架主義有著不同程度的理解和應用，但這并不代表他們不具備學習能力或意愿。他們渴望做出好的成績，而管理層應該負責明確什么才是“做好工作”。許多新手開發者可能了解 React，但他們在職業生涯中會接觸和掌握十幾種其他工具，而 React 無疑是其中最復雜（且不必要）的一個。

認為那些已經掌握了 React 及其相關技術的恐怖之處的人，無法接受 DOM 生命周期方法、事件循環或現代 CSS，這簡直是一種侮辱且毫無根據。這種不公平的刻板印象不僅限制了團隊潛力，也凸顯了管理的失敗。

換句話說，這就是管理層的極大失敗。

“……現在每個人都有快速的手機了”

十多年來，框架主義一直堅持一個核心觀點：客戶端資源成本低廉，因此為了開發者的便利，犧牲一些用戶端性能是合理的。這一觀點已被證實是一場徹底的失敗。至少從 2012 年開始，移動設備的興起就駁斥了這一論點，而我們剛剛開始意識到問題的嚴重性。

所謂“現在每個人都有快速的手機”的論調，首先暴露了提出者自身的無知，同時也寄希望于聽眾也不了解實際情況。任何試圖在網絡上立足的企業都無法承受這種錯誤理念帶來的后果，你也沒有理由為了迎合這種錯誤的信念而犧牲產品的質量。

“……React 是行業標準”

這種說法，最多不過是一種令人感到安慰的謊言。

更糟糕的是，它可能是一種故意為之的虛假陳述，旨在掩蓋基于 React 的不同技術棧間的顯著差異。事實上，React 不是一個固定的技術，而更像是一個包含多種選擇的生活方式：你需要決定使用函數組件還是類組件；是否采用 TypeScript；選擇哪個包管理器（如 npm、yarn 或 pnpm）；以及使用哪種打包工具（如 webpack、esbuild、SWC 或 rollup）。此外，還有元工具（如 Vite、Turbopack 或 Nx）和狀態管理工具（如 Redux、MobX 或 Apollo）等選擇。甚至在 CSS 處理方面，也有不同的插件和方法可以選擇。例如，“CSS-in-JS”就是一個特別不合理的選項。

在超過 100 次的咨詢項目中，我從未見過兩個完全相同的 React 配置，除非是那些尚未更改 Create React App 默認設置的小型項目。而這個工具本身也隨著 React 的發展經歷了多次重大變更，最終從官方文檔中消失，不再是推薦的入門方式。

這一切都說明，所謂的“標準”并不存在。所有的技術和工具都在持續演變，任何告訴你“React 是行業標準”的人都不值得信任。

毫無意義的斷言

希望你能原諒我稍微偏離主題，探討一下“React 是行業標準”這一誤導性觀念為何會如此深入人心。

盡管有大量證據表明，這些技術甚至連那些被視為 React 成功案例的網站都無法有效運作，為什么 React 仍然廣泛存在于現代前端開發的各個角落呢？

原因在于，那些自認為無所不知的人們通過強力推廣實現了這一點。框架主義者往往用簡單的斷言如“虛擬 DOM 意味著更快的速度”來主導每一項討論，但實際上他們對瀏覽器的工作機制一無所知，更不用說理解其替代方案帶來的高昂垃圾回收（GC）成本了。這種無知使他們能自信地宣稱 React 是“沒問題的”——即使在各個維度上都存在更經濟高效的替代方案。

這些人并不值得認真對待。你不需要把他們的話當真，但你必須要反對他們，并建立以數據為驅動、以用戶為核心的架構。這些錯誤決策的長期成本是巨大的，正如我們所見，許多團隊不得不尋求幫助，以修復那些號稱“高性能”的技術棧所帶來的性能問題。

“……生態系統……”

具體是指哪個部分呢？請極其明確地指出。哪些包對 React 綁定得如此緊密，以至于團隊不應該考慮其他替代方案？這些包真的不能與 Preact 一起使用嗎？為了使用這些庫，究竟需要付出多少成本才是合理的？因為這才是討論的核心。

即使你在開始時確實享受到了“生態系統”的好處，為什么你認為這種優勢會持續下去？

每個庫都存在被遺棄的隨機風險。即使是最常用的系統，也會因 JS 工業圈的風云變幻而失寵，最終讓你處于和一開始就選擇更自主構建棧但經驗較少、掌控力較弱的情況下相同的位置。這真是個明智的交易嗎？你的老板會同意嗎？

順便問一句，那個“CSS-in-JS”的冒險進行得如何？你們還在寫類組件，還是已經經歷了一次大規模且不完全的遷移，而現在仍然在處理由此帶來的各種問題？

事實上，每一個作為 devDependencies 依賴項的包，現在或將來都將由消費者全權負責。避免意外驚喜的唯一防線是，將 NPM 依賴視為一種高利貸，而抵押的資本是未來的工程能力。

防止這些成本失控的最佳方法是對每個 UI 工具和構建系統的依賴進行全面審查和批準。如果你的團隊不愿意承擔所有這些系統的所有權、修復和改進責任，那它們就不應該成為你技術棧的一部分。

“……Next.js 可以很快”

你覺得自己幸運嗎？真的覺得幸運嗎？——因為要實現這一概率，你需要相當的幸運。

用 Next.js 構建的網站性能明顯不如那些 HTML 優先的系統，如 11ty、Astro 等。

Next.js 不僅難以擴展，而且它捆綁 React 的做法就像帶著沉重的枷鎖，這是雙重不利因素。任何 Next.js 站點默認延遲加載的龐大 JavaScript 負載會與其他業務關鍵的延遲內容爭奪帶寬，這還不算添加任何自定義組件或路由時的負擔。即使使用了 React 服務器組件情況也是如此。換句話說，Next.js 是一個快速燒錢的選擇，同時會將你鎖定在一個由風險投資支持的初創公司專有的 API 中。

Next.js 從一開始就不是最優選，并且隨著項目的推進，其劣勢愈發明顯。難怪只有那些用戶基礎極富有的 Next.js 站點，或者得到了 Vercel 精心調優支持的站點，才會表現出較好的性能。

所以，你覺得自己足夠幸運嗎？

“……React Native！”

React Native 是一種制作緩慢應用的好方法，且需要不斷調試；同時，它也是制作糟糕網站的極佳選擇，甚至曾經作為其成功案例的一些公司也已經逐漸放棄了它。

那些希望通過與網站共用代碼庫向應用商店交付引人注目的移動體驗的公司，應該更傾向于研究 Trusted Web Activities 和 PWABuilder。如果這些方案不可行，Capacitor 和 Cordova 也能提供類似的好處。這些方法可以讓大多數原生功能可用，但將 UI 投資集中在 Web 端，通過單一路徑提供可見性和控制力，從而減少重復優化和可訪問性問題帶來的困擾。