Chris Ferdinandi 的 Smashing Podcast 第 21 集：現代最佳實踐對 Web 不利嗎？

今天，我們要問的是現代最佳實踐是否對網絡不利？ 現代框架是否將我們帶入了錯誤的道路？ 我與精益網絡專家 Chris Ferdinandi 進行了交談以找出答案。

顯示註釋

• Chris 的頁面，其中包含播客的鏈接和註釋
• 精益網絡書
• 克里斯·費迪南迪在網絡上
• 克里斯在推特上
• 香草 JavaScript 播客

每週更新

• “將設計線框轉換為可訪問的 HTML/CSS”
  哈里斯·施耐德曼
• “使用 Electron 和 Vue 構建桌面應用程序”
  蒂米·奧莫耶尼
• “提高易讀性的現代 CSS 技術”
  愛德華多·卡瓦扎
• “如何在 React 中使用樣式化組件”
  作者：阿德比伊 Adedotun Lukman
• “如何使用草圖創建保時捷 911”
  尼古拉·拉扎雷維奇

成績單

Drew McLellan：他是 Vanilla JS 袖珍指南系列的作者，Vanilla JS 學院培訓計劃的創建者，以及 Vanilla JS 播客的主持人。 他開發了一份 Tips 時事通訊，每個工作日都有近 10,000 名開發人員閱讀。 他曾在 Chobani 和 The Boston Globe 等組織教授開發人員。 他的 JavaScript 插件已被 Apple 和哈佛商學院等組織使用。 最重要的是，他喜歡幫助人們學習 Vanilla JavaScript。 所以我們知道他寧願選擇 Vanilla JavaScript 而不是框架，但你知道他曾經在警察陣容中被選為最不可能犯罪的人嗎？ 我的 Smashing 朋友，請歡迎 Chris Ferdinandi。 你好，克里斯。 你好嗎？

克里斯·費迪南迪：哦，我太棒了。 感謝您的款待。

德魯：我今天想和你談談精益網絡的概念，這對你來說是一種熱情，不是嗎？

克里斯：是的，非常如此。

德魯：你為什麼不為我們設置場景？ 當我們談論精益網絡時，我們試圖解決的問題是什麼？

克里斯：是的，很好的問題。 就像對所有聽眾的警告一樣，這一集可能會讓一個小老頭對雲大喊大叫。 我會盡量避免這種情況。 當我看到我們今天為網絡構建的方式時，感覺有點像一個臃腫的過度設計的混亂。 我開始相信，我們今天認為的許多最佳實踐實際上可能會讓網絡變得更糟。

Chris：精益 Web 是一種專注於簡單性、性能和開發人員體驗的 Web 開發方法……對不起，不是開發人員體驗。 用戶體驗，而不是開發人員體驗，以及從團隊的角度構建事物的便利性，這是我認為我們今天非常關注的地方，並且我們可能會在我們的對話中進行討論。

Chris：實際上，我發現很多我們認為可以改善開發人員體驗的事情對一小部分開發人員來說都是如此，但不一定是所有在你正在構建的東西上工作的人。 所以這也有很多問題，我們可以深入研究。 但實際上，精益網絡關注的是用戶的簡單性和性能，並真正優先考慮或關注使用我們製造的東西的人，而不是我們，製造它的人。

Drew：隨著網絡作為開發平台的成熟，似乎有越來越多的專業化驅動力。

克里斯：是的。

Drew：以前是覆蓋Full Stack的人，後來我們分成前端和後端。 然後前端分裂成從事 CSS 或 JavaScript 開發的人。 然後越來越多地在 JavaScript 中，它變得更加專業化。 有人可能會認為自己並將自己推銷為 React 開發人員或 Angular 開發人員，他們的整個身份和前景都基於他們精通的特定框架。這種對框架的依賴是我們在 Web 上工作的核心嗎？壞事？

克里斯：這是微妙的。 我曾經非常強烈地支持“是的，永遠”陣營。 我認為從廣義上講，我仍然認為是的，我們作為一個對框架和工具的行業的痴迷確實可能有點損害我們的利益。 我不認為框架本質上是壞的。 我認為它們對於非常狹窄的用例子集很有用。 我們最終將它們用於幾乎所有事情，包括許多情況，它們實際上不一定是您或項目的最佳選擇。

克里斯：當我想到我們今天在網絡上遇到的許多問題時，這些問題的核心實際上始於我們對框架的過度依賴。 之後發生的所有其他事情在很多方面都是如此，因為我們在網絡上拋出的不僅僅是一般的 JavaScript 框架。 我這麼說是作為一個專業地教人們如何編寫和使用 JavaScript 的人。 這就是我賺錢的方式。 我在這裡是說我認為我們使用了太多的 JavaScript，這有時有點奇怪。

Drew：在大型框架出現之前，我們曾經使用 jQuery 或其他東西來構建用戶界面和東西。 然後框架出現了，它們給了我們更多關於基於狀態的 UI 的概念。

克里斯：是的。

德魯：現在，這是一個相當複雜的工程，你需要到位。 使用較少的 JavaScript 會排除使用類似的東西，還是您必須自己重新實現它？ 你只是在創建一個加載的樣板嗎？

克里斯：很大程度上取決於你在做什麼。 如果你有一個不變的界面，你可以構建一個基於狀態的 UI……我不知道，可能有十幾行代碼。 如果你有一個不變的界面，老實說我可能會說基於狀態的 UI。 這不一定是正確的方法。 您可能還可以做其他事情。 想想靜態站點生成器、一些預渲染的標記，甚至是老式的 WordPress 或 PHP 驅動的站點。

克里斯：但是當你進入更加動態和交互式的界面時，這開始變得有趣。 不僅僅是應用程序。 我知道人們喜歡在網站和應用程序之間劃清界限，我認為兩者之間存在這種奇怪的混合，而且界限並不總是那麼清晰。 當您開始深入了解用戶所做的事情時，就會發生一些變化。 基於狀態的 UI 變得更加重要。 但是你仍然不需要大量的代碼來實現這一點。

Chris：我看 React 或 Vue 之類的東西，它們絕對是令人驚嘆的工程。 我不想剝奪從事這些工作的人。 我最終作為一個學習練習，構建了我自己的迷你框架，只是為了更好地了解這些東西是如何在幕後工作的。 很難解釋所有不同的移動部分。 所以我非常尊重那些構建和使用這些工具的人。 但是 React 和 Vue 在壓縮和 gzip 壓縮後都是大約 30 KB。 所以一旦你打開它們，它們就會比這大得多。

克里斯：不是全部，但其中很大一部分是用於稱為虛擬 DOM 的東西。 有使用類似 API 或方法的替代方案。 對於 React，你有 Preact，它是 2.5 KB 或大約 3 KB，而不是 30。它是大小的十分之一。 對於 Vue，你有 Alpine JS，大約 7 KB。 儘管如此，還是要小得多。 這些和他們的老大哥同行之間的最大區別在於他們擺脫了虛擬 DOM。 他們可能會放棄一兩個方法。 但總的來說，在處理代碼的方式上，它是相同的方法和相同類型的 API，而且它們要小得多。

克里斯：我認為我們使用的很多工具對於我們正在嘗試做的事情來說可能過於強大了。 如果您需要基於狀態的 UI，並且需要響應式數據和這些動態界面，那就太好了。 我認為我今天嘗試談論的一件大事不是……永遠不要使用工具。 對我來說，Vanilla JS 並不是你在手寫每一行代碼和你所做的每一個項目。 那是瘋狂。 我不能那樣做，我不那樣做。 但它對我們使用的工具更具選擇性。 我們總是選擇多功能工具，即擁有所有這些東西的瑞士軍刀。 有時，你真正需要的只是一把剪刀。 你不需要所有其他的東西，但無論如何我們都有。

克里斯：這真的是一個很長的路要走……我很抱歉，回答你的問題。 有時它比您自己編寫或想要編寫的代碼多，但它並不像我認為我們認為它需要的那麼多代碼。 當我說你不需要框架時，我對這個想法有很多反對意見，“好吧，如果你不使用框架，你基本上是在編寫自己的。” 隨之而來的是它自己的問題。 我認為在使用 React 或 Vue 和編寫自己的框架之間有一個地方，它可能會選擇一些更小的東西。 有時，編寫自己的框架實際上可能是正確的選擇，這取決於您要嘗試做什麼。 這一切都非常流暢和主觀。

Drew：非常有趣的是，作為一個學習練習，您實現了自己的基於狀態的框架。 我記得在過去，我曾經認為每次我伸手去拿圖書館或其他東西時，我都喜歡認為我可以自己實現它。

克里斯：當然，當然。

德魯：但是去圖書館為我省去了這樣做的麻煩。 我知道如果我必須自己編寫這段代碼，我知道我會採取什麼方法來完成它。 一直到使用 jQuery 之類的東西都是如此。 這些天來，我想如果我必須編寫自己的 Vue 或 React 版本，我幾乎不知道現在在那個庫中發生了什麼，在所有代碼中。

Drew：對於我們這些不熟悉的人來說，當你說 Preact 放棄了虛擬 DOM 並使一切變得更小時，虛擬 DOM 給了我們什麼？

克里斯：要回答這個問題，我想稍微退後一步。 框架和其他基於狀態的庫為您提供的最好的東西之一就是 DOM diff。 如果你並沒有真正更新 UI，你可以說：“這是標記應該是什麼樣子的字符串。 在 HTML 中，我將把所有這些標記放在這個元素中。” 當你需要改變某事時，你會再做一次。 這對瀏覽器來說有點貴，因為它會觸發重繪。

克里斯：但我認為可能比這更重要的是，這樣做的一個問題是你有任何類型的交互式元素，一個表單域，一個有人關注的鏈接。 因為元素失去了焦點……即使你有一個看起來相似的新事物，它也不是同一個字面元素。 因此，如果失去焦點，可能會給使用屏幕閱讀器的人造成混亂。 這只是一大堆問題。

Chris：任何值得重視的基於狀態的 UI 都將實現一些 DOM diffing，他們說，“這就是 UI 應該是什麼樣子。 這是它現在在 DOM 中的樣子。 有什麼不同？” 它會去改變那些事情。 它實際上是在做你自己手動更新 UI 會做的事情，但它是在幕後為你做的。 所以你可以說，“這就是我想要的樣子。” 然後庫或框架會計算出來。

Chris：像 Preact 或 Alpine 這樣的小東西，他們實際上是直接這樣做的。 他們正在將您提供給他們的關於 UI 外觀的字符串轉換為 HTML 元素。 然後他們將每個元素與文字 DOM 中的相應部分進行比較。 當你最終得到越來越大的 UI 時，這可能會對性能產生影響，因為一遍又一遍地查詢 DOM 變得昂貴。 如果您想了解成為問題的界麵類型，請右鍵單擊並檢查 Twitter 上的“收藏”按鈕或 Facebook 上的“喜歡”按鈕上的元素。 並查看讓您進入該元素的 div 嵌套。 它非常非常深。 它就像十幾個 div，一個嵌套在另一個里面，只是為了那條推文。

克里斯：當你開始向下很多層時，它開始真正影響性能。 虛擬 DOM 所做的不是每次都檢查真實的 DOM，它會創建一個基於對象的映射，以反映 JavaScript 中 UI 的樣子。 然後對要替換現有 UI 的 UI 執行相同的操作，並將這兩者進行比較。 理論上，這比在真實 DOM 中的性能要高得多。 一旦它獲得了需要更改的內容的列表，它就會運行並進行這些更改。 但它只需要攻擊 DOM 一次。 它不是每次都檢查每一個元素。 如果您有 Twitter、Facebook 或 QuickBooks 之類的界面，那麼虛擬 DOM 可能會很有意義。

Chris：它面臨的挑戰是...... Preact 和 React 之間的差異是 27 KB，然後你將整個東西解壓縮到它的實際代碼波中。 僅此一項的原始下載、解包和編譯時間就會給 UI 上的初始加載增加相當多的延遲。 如果您的用戶使用的不是 Apple 的最新設備，這一點會更加明顯。 即使是幾年前的 Android 設備或功能手機，或者如果你有發展中國家的人，這真的是……開始的時間要慢一些。 然後最重要的是，由於額外的抽象，實際的交互時間更慢。

克里斯：所以不僅僅是你加載它，它們在速度上也相當。 某人進行的每個微交互以及需要發生的更改也可能會稍微慢一些，因為那裡有所有額外的代碼。 如果您有一個非常非常複雜的 UI，其中包含大量嵌套元素和大量數據，那麼虛擬 DOM 的性能增益將超過額外的代碼量。 但是，對於我看到的大多數開發人員使用 React 或 Vue 的典型應用程序的任何典型 UI，你從虛擬 DOM 中獲得的好處都不存在，他們會做得更好。 即使您想保持與 React 相同的便利性，也請使用 Preact。 它只是尺寸的一小部分，它的工作方式完全相同，而且性能更高。 這是我傾向於爭論的事情。

克里斯：我們需要更好地為工作選擇正確的工具。 如果你採用這樣的方法，如果你達到了虛擬 DOM 真正有意義的地步，那麼將 Preact 移植到 React 比使用自己的方法要容易得多。 情況就是這樣。 如果您真的對此感到擔心，那麼您也可以內置一些面向未來的功能。

Drew：有些人可能會說，他們可能會認為這些框架，比如 Vue、React 都針對性能進行了高度優化，以至於你在那裡獲得了很多好處，當然只需將其與捆綁器中的包管理器配對以確保你僅發送您想要的代碼。 當然，您這樣做就已經遙遙領先了？

克里斯：是的。 我不同意。 除了……我想也許，但不是真的。 即使使用捆綁器，您仍然需要那個 React 核心。 即使有捆綁，這仍然比使用 Preact 之類的東西要大。

克里斯：德魯，我真的很感謝你提出這個問題。 因為我在我的書《精益網絡》和我的同名演講中談到的另一件事是這些工具如何……例如，您提到了捆綁。 為了解決使用所有這些 JavaScript 所帶來的性能損失，我們所做的其中一件事是我們在前端拋出了更多的 JavaScript 來解決這個問題。 我們這樣做的方法之一是包管理器和模塊捆綁器。

Chris：正如你所提到的……對於那些不知道的人來說，這些工具將……它們會將你所有的單獨 JavaScript 位編譯成一個大文件。 新的和更多的……我不想稱他們為深思熟慮的。 但是較新的將使用一種稱為搖樹的功能，他們可以擺脫任何實際上不需要的代碼。 如果該代碼有一些未用於您實際完成的事情的依賴項，他們將刪除其中的一些內容以使您的包盡可能小。 這實際上不是一個糟糕的想法，但它導致了我通常稱之為依賴健康的東西，在這種情況下，你可以在依賴關係之上擁有這個非常精緻的依賴關係卡片之家。

克里斯：設置您的流程需要時間。 任何曾經運行過 NPM 安裝然後發現一堆依賴項已經過時並且不得不花費一個小時試圖找出哪些需要修復的人，哦，它實際上是依賴項中的一個依賴項，而你不需要沒有能力自己去修。 這是一整件事。 也許它對你有用，但我寧願花時間不要試圖把我的依賴關係放在一起。

克里斯：我已經開始收集人們抱怨在工作流程上浪費時間的推文。 幾年前，我最喜歡的一位 Brad Frost 談到了一個令人沮喪的認識，即你在現代 JS 中苦苦掙扎的事情可能在 jQuery 中花費了你 10 分鐘。 我不是一個真正的 jQuery 粉絲，但是當涉及到使用框架時，我感到很痛苦。

克里斯：很多這些工具的另一個問題是它們開始成為看門人。 德魯，我不知道你是否真的想深入研究這個。 但我對 JS 的最大反對之一是工作流程中的所有事情。 尤其是當你開始說，“好吧，如果我們已經將 JS 用於 HTML，為什麼不將它也用於 CSS？” 你開始將很多真正有才華的人排除在開發過程之外。 對於整個社區來說，這對項目來說是一個非常大的損失。

Drew：嗯，我當然是……我在 2020 年初開始學習 React，並將其添加到我的技能中。 我已經做了將近七個月了。 我不得不說我最不自信的一部分是圍繞啟動項目設置工具。

Drew：似乎有很多工作要為 Hello World 提供一些東西，而且您還需要了解更多內容才能將其投入生產。 如果將其作為您在 2020 年學習成為 Web 開發人員應該做的事情提出來，那麼這必須使開發更難開始。 剛接觸它的人會遇到真正的問題。 這將是一個真正的進入障礙，不是嗎？

克里斯：當然。 這裡的另一部分是 JavaScript 開發人員並不總是唯一在代碼庫上工作或以有意義的方式為該代碼庫做出貢獻的人。 我們越是讓了解 JavaScript 成為使用代碼庫的必要條件，這些人就越不可能真正參與到項目中。

克里斯：我喜歡談論的一個例子是 WordPress，它最近……我現在不應該說最近。 現在已經一兩年了。 但是他們已經越來越多地將後端堆棧轉移到 JavaScript，遠離 PHP，這本質上並不是一件壞事。 他們的新編輯器 Gutenburg 是基於 React 構建的。

克里斯： 2018 年，WordPress 的首席可訪問性顧問 Rian Rietveld，我幾乎可以肯定他的名字被我屠殺了……她非常公開地辭去了她的職位，並在一篇非常詳細的文章中記錄了原因。 問題的核心是她和她的團隊的任務是審核這個編輯器，以確保它可以被訪問。 WordPress 現在佔網絡的 30%。 他們的目標是使出版民主化，因此可訪問性是其中非常重要的一部分。 它應該是任何 Web 項目的重要組成部分。 但對於他們來說，這尤其重要。 她團隊的全部工作是確保……她團隊的全部工作是確保該編輯器可以訪問。 但是因為她和她團隊中的任何人都沒有 React 經驗，而且他們在無障礙社區中找不到有這種經驗的志願者，這讓她和她的團隊很難完成他們的工作。

克里斯：從歷史上看，他們可以識別錯誤，然後進行修復。 但是使用基於 React 的新工作流程，他們只需要識別錯誤然後提交工單。 它們與 JavaScript 開發人員正在處理的所有其他功能開發請求一起被添加到積壓工作中。 很多本可以很容易修復的東西並沒有進入第一個版本。

Chris： 2019 年 5 月，也就是 Rian 辭職大約一年後，對 Gutenburg 進行了詳細的可訪問性審核。 完整的報告有 329 頁。 僅執行摘要就有 34 頁。 它非常詳細地記錄了 91 個與可訪問性相關的錯誤。 其中許多真的是……我不想稱它們為簡單的唾手可得的果實，但其中很多都是 Rian 的團隊可以修復的基本問題，它可以讓開發人員騰出精力專注於功能開發。 這就是他們最終似乎在做的事情，花了很多時間在功能開發上，並將這些東西推遲到以後。 但是那個團隊對這個項目非常重要，他們突然因為技術選擇而被排除在這個過程之外。

Chris： Alex Russell 是 Chrome 團隊的開發人員。 幾年前，他寫了一篇名為 The Developer Bait and Switch 的文章，其中他談到了框架的稻草人論點。 這些工具可以讓您更快地移動，因此，您可以更快地迭代並提供更好的體驗。 正是這個想法，更好的開發者體驗意味著更好的用戶體驗。 我認為這是一個非常清楚的例子，說明該論點並不總是以人們認為的方式發揮作用。 對於某些人來說，這可能是一種更好的體驗，而不是對所有人。

Chris： CSS 開發人員，從事設計系統工作的人，他們創建其他人可以使用的工具的能力有時也會受到這些工具選擇的限制。 根據我的經驗，我曾經更擅長 CSS。 在過去的幾年裡，情況發生了很大變化，我遠不如從前那麼好。 以我的經驗，真正高級的 CSS 開發人員……我的意思是真正意義上的。 從事 CSS 工作的人是從事編程語言的合適的 Web 開發人員。 這是一個非常特別的，或者可以是一個非常專業的東西。 根據我的經驗，特別擅長 JavaScript 的人並不總是非常擅長 JavaScript，因為你最終會真正深入地研究一件事，並且在其他一些東西上滑了一點點。 他們使用這些技術的能力也受到了阻礙，這太糟糕了，因為過去並非如此。

Chris：當堆棧更簡單時，來自多個學科的人更容易參與開發過程。 我認為這對我們構建的東西和整個社區都是有害的，而情況不再如此。

Drew：我最近在一個項目中發現，該項目正在研究處理一些 CSS 問題、工作流問題的方法，我們在該項目上進行了多次工作，並且捆綁包的大小不斷增加，而舊的 CSS 永遠不會被刪除。 這是一個 React 項目，所以我們在 JavaScript 中研究了其中的一些 CSS 方法，以了解最適合我們用來解決我們遇到的問題的方法。 很快就顯而易見的是，不僅有一種解決方案可以做到這一點。 有幾十種不同的方法可以做到這一點。

Drew： JS 中的 CSS 是一種通用方法，但您可能會從一個項目轉到下一個項目，它會以完全不同的方式受到影響。 即使您是一名 CSS 人員並且您在項目中學習了一種特定的方法，這些技能也可能無法轉移。 如果某人對 JavaScript 不是特別熟悉，那麼很難看出他們應該如何投入太多時間來學習這一點。

克里斯：是的。 另一件有趣的事情，我認為你剛剛說出來的一點是，當我談到這個時，我得到的最大的回擊之一是框架強制執行約定。 你將使用 Vanilla JavaScript，你有這片綠色的田野——藍天，你可以做任何你想做的項目。 有了 React，就有了一種 React 做事的方式。

Chris：但我發現的一件事是有 Reacty 方法，但沒有一種嚴格的正確方法來使用 React 做事。 這是人們喜歡它的原因之一。 它更靈活一點，如果你願意，你可以用幾種不同的方式做事。 與 Vue 相同。 您可以使用基於 HTML 的東西，在 HTML 中正確設置屬性，然後 Vue 替換它們，但如果您願意，也可以使用更類似於 JSX 的模板語法。

Chris：我聽過很多人在學習 React 時抱怨，其中一個大問題是你用谷歌搜索如何在 React 中做 X，然後你會看到十幾篇文章告訴你可以用十幾種不同的方式來做這件事。 這並不是說他們不對項目設置一些護欄。 我不認為它像“我選擇了一個框架”那麼明確。 現在這就是我用它構建的方式。” 老實說，我也不知道那一定是我想要的。 我不認為你會想要那些被嚴格限制的……也許有些人會想要。 但如果你吹捧這是一種好處，我認為它並不像人們有時所說的那樣明顯。

克里斯：你剛剛遇到了一件有趣的事情，你提到了不再需要的 CSS。 我認為這是合法有趣的事情之一，比如 CSS 和 JS……或者以某種方式將你的 CSS 與 JavaScript 組件聯繫起來，如果該組件退出，CSS 在理論上也會隨之消失。 對我來說，其中很多感覺就像把工程扔給人們的問題。 總是，你仍然依賴於沿線某個地方的人。 這並不是說永遠不要使用這些方法，但它們肯定不是解決這個問題的唯一方法。

Chris：您可以使用一些工具來審核您的 HTML，並提取即使不使用 CSS 和 JavaScript 也不會使用的樣式。 你可以用“老式的方式”編寫 CSS，並且仍然對未使用的樣式進行 linting。 有一些 CSS 創作方法可以為您提供類似 JS 的輸出中的 CSS，並保持您的樣式表很小，而不會吐出您有時使用 CSS 和 JS 獲得的這些胡言亂語的人類不可讀的類名。 像 X2354ABC，或者只是這些被吐出來的廢話。

克里斯：這就是我開始真正了解老人對雲大喊大叫之類的事情的地方。 我真的在這裡展示了我的開發人員年齡。 但是，是的，這些東西不一定是壞事，它們是為解決合法問題而設計的。 有時我覺得有點……如果它對 Facebook 來說足夠好，那麼對於我們這種發生在這些事情上的事情來說就足夠好了。 好吧，Facebook 使用了這個工具。 如果我們是一個真正的工程項目……團隊、部門、組織，我們也應該這樣做。 我不一定認為這是正確的思考方式。 這是因為 Facebook 會處理您不處理的問題，反之亦然。 他們所從事的工作的規模和規模是不同的，這沒關係。

德魯：沒錯。 我看到其中一些像 CSS 和 JavaScript 幾乎就像一個 polyfill。 我們有合法的問題，我們需要一種方法來解決它。 該技術還沒有為我們提供解決它的方法。 也許當我們等待網絡平台發展並解決這個問題時，我們現在用 JavaScript 做的這件事會讓我們度過難關，我們會沒事的。 我們知道這很糟糕。 我們知道這不是一個很好的解決方案，但它現在對我們有幫助。 並希望在此期間我們可以將其拉出來並使用本機解決方案。

克里斯：你提起這個真的很有趣。 因為從字面上看，昨晚，我正在觀看 Jeremy Keith 去年關於漸進式網絡應用程序的演講。 但他說的是幾十年前，他試圖說服人們使用 JavaScript。 這在當時看起來很荒謬，但 JavaScript 是一個新事物。 他向人們展示瞭如何做一些很酷的事情，比如用這個新的改變懸停時鏈接的顏色……現在你需要 JavaScript 似乎很荒謬，因為這就是 CSS 為你做的。 但是當時並不存在諸如焦點屬性或屬性之類的東西。

Chris：他在演講中說的其中一件我認為真正引起我共鳴的事情是 JavaScript 在很多方面都鋪平了那些牛路。 這是一種非常靈活和開放的語言，我們可以使用它來創建或插入尚不存在的功能。 最終，瀏覽器會趕上並以更原生的方式實現這些功能。 但這需要時間。 我完全理解你在說什麼。 這不是完美的解決方案，但它是我們現在所擁有的。

Chris：我認為，對我來說，polyfills 和其中一些解決方案之間的最大區別在於，polyfills 被設計為被淘汰。 如果我想要實現瀏覽器尚不支持的功能，但有某種規範，我編寫了一個 polyfill……一旦瀏覽器趕上，我可以撕掉那個 polyfill 而我不必改變任何東西。 但是當你走上使用這些工具的道路時，把它們撕掉就意味著重寫你的整個代碼庫。 這真的很昂貴而且有問題。 這並不是說永遠不要使用它們，但我非常強烈地認為我們應該考慮選擇以後可以輕鬆取出的工具。 如果我們不再需要它們或平台迎頭趕上，它不需要大量的重寫來將它們拉出來。

克里斯：因此，我們有一大堆不再使用的樣式，這就是為什麼我個人傾向於一種構建工具技術，它可以根據渲染的標記審核你的 CSS 並提取你不需要的東西。 因為如果一個平台趕上來，你可以把那部分構建工具拉出來，而不必改變一切。 它只是增加了你已經擁有的東西，而 CSS 和 JS 並沒有給你同樣的好處。 我只是選擇那個，但我更廣泛地考慮了很多這些技術。

Chris：我確實覺得像 React 或 Vue 這樣的東西可能正在鋪平一些瀏覽器最終會趕上的牛路，並且可能會使用類似的方法（如果不一樣的話），因此可能涉及的重寫更少。 許多被插入的生態系統東西可能不那麼重要。

Drew：我認為網絡平台緩慢而謹慎地移動是正確的，不是嗎。 您認為如果五年前，我們都將 JavaScript 輪播放在我們的頁面上。 他們無處不在。 每個人都在實現 JavaScript Carousels。 如果 Web 平台已經跳出並實施了 Carousel 解決方案來滿足該需求，那麼它就不會坐在那里而沒有人使用它，因為人們不再使用 Carousels 來做這件事了。 因為它只是一種時尚，一種設計趨勢。 為了抵​​消這一點並阻止平臺本身變得臃腫並成為需要解決的問題，它確實必須以更穩定的速度移動。 The upshot of that is HTML that I wrote in 1999 still works today because of that slow process.

Drew: One of the other areas where things seem to be bloating out on the web is… I guess it's related to the framework conversation. But it's the concept of a single-page app. I feel like that a lot of promises are made around single-page apps as to their performance, like you're getting all this benefit because you're not reloading the entire page framework. I feel like they don't always make good on those performance promises. 你同意嗎？

Chris: Yes. Although I will confess, despite having a very lengthy chapter in my book on this and talking about that a lot in talks and conversations with people, I don't think single-page apps are always a terrible thing. But I do think this idea that you need one for performance is overstated. You can oftentimes get that same level of performance with different approaches.

Chris: I think one of the bigger challenges with single-page apps is… For anybody who's unfamiliar with those. When a single-page app, instead of having separate HTML files or if you're using something like a database driven site like WordPress, even though you don't have actual physical HTML files for each page in your WordPress site, WordPress is creating HTML files on the fly and sending them back to browsers when URLs are requested. For purposes of this conversation, instead of having separate HTML files for every view in your app, a single-page app has a single HTML file. That's what makes it a single-page app. JavaScript handles everything. Rendering the content, routing to different URL paths, fetching new content if it needs to from an API or something like that.

Chris: One of the spoken benefits of these or stated benefits of these is that only the content on the page changes. You don't have to re-download all the JS and the CSS. Oh, and you can do those fancy page transitions that designers sometimes love. In theory, this is more performant than having to reload the whole page.

Chris: The problem with this approach from my perspective is that it also breaks a bunch of stuff that the browser just gives you for free out-of-the-box, and then you need to recreate it with more JS. You have an app that's slow because it has a lot of JS. So you throw even more JavaScript at it to improve that performance and in doing so, you break a bunch of browser features and then have to re-implement those with even more JS too.

Chris: For example, some things that the browser will do for free with a traditional website that you need to recreate with JavaScript when you go the single-page app. You need to intercept clicks on links and suppress them from actually firing, with your JavaScript. You then need to figure out what you actually need to show based on that URL, which is normally something that would get handled on the server or based on the file that goes with that URL path. You need to actually update the URL in the address bar without triggering a page reload. You need to listen for forward and back clicks on the browser and update content again, just like you would with clicks on links. You need to update the document title.

Chris: You also need to shift focus in a way that announces the change in page to people who are using screen readers and other devices so that they're not confused about where they are or what's going on. Because they can't see the change that's happening, they're hearing it announced. If you don't actually shift focus anywhere, that announcement doesn't happen. These are all things that the browser would do for you that get broken with single-page apps.

Chris: On top of that, because you have all this extra JavaScript, this is complicated. So most people use frameworks and libraries to handle this sort of thing. Because of all this extra JavaScript to support this approach, you end up with potentially slower initial page load than you would have otherwise. Depending on the content you have, this approach I think sometimes can make sense. If you have an app that is driven by API data where you don't necessarily know what those URL paths are going to look like ahead of time.

Chris: Just an example here. You have an animal rescue where you have some adoptable animals, and that data comes from Petfinder, the animal adoption website. You have a bunch of animals there. Petfinder manages that, but you want to display them on your site with the Petfinder API. When your website's being built, it doesn't always necessarily have visibility to what pets are available in this exact moment and what kind of URL paths you're going to need. A single-page app can help you there because it can dynamically on the fly, create these nice URLs that map with each dog or cat.

Chris: Something like Instagram with lots of user created content, maybe that also makes sense. But for a lot of things, we do know where those URLs are going to be ahead of time. Creating an HTML file that has the content on it already is going to be just as fast as… sometimes even faster than the JavaScript based single-page app approach, especially if you use some other techniques to keep your overall CSS and JavaScript size down. I use this approach on a course portal that I have. The page loads feel instantaneous because HTML is so easy for browsers to render compared to other parts of the stack. It feels like a single-page app, but it's not.

Drew: Especially when you consider hosting solutions like a Jamstack approach of putting HTML files out in a CDN so it's being served somewhere physically close to the user.

Chris: Yep.

Drew: Loading those pages can just be so, so quick.

Chris: Yes. 絕對地。 絕對地。 One of the other arguments I think people used to make in favor of single-page apps is offline access. If someone loads it and then their network goes down, the app is already up and all the routes are handled just with the file that's already there. So there's no reloading, they don't lose any work. That was true for a long time. Now with service workers and progressive web apps, that is I think less of a compelling argument, especially since service workers can fetch full HTML files and cache them ahead of time if needed.

Chris: You can literally have your whole app available offline before someone has even visited those pages if you want. It just happens in the background without the user having to do anything. It's again, one of those technologies that maybe made sense for certain use cases a few years ago a little less compelling now.

Drew: It reminds me slightly of when we used to build websites in Flash.

Chris: Yes.

Drew: And you'd have just a rectangle embedded in an HTML page which is your Flash Player, and you'd build your entire site in that. You had to reimplement absolutely everything. There was no back button. If you wanted a back button, you had to create a back button, and then you had to create what the concept of a page was. You were writing code upon code, upon code to reimplement just as you are saying things that the browser already does for you. Does all this JavaScript that we're putting into our pages to create this functionality… is this going to cause fragility in our front-ends?

Chris: Yes. This is almost certainly from my mind, one of the biggest issues with our over-reliance on JavaScript. JavaScript is just by its nature, is a scripting language, the most fragile part of the front-end stack.

Chris: For example, if I write an HTML element that doesn't exist, I spell article like arcitle instead of article and the browser runs across that, it's going to be like, “Oh, I don't know what this is. Whatever, I'll just treat it like a div.” And it keeps going. If I mistype a CSS property… Let's say I forget the B in bold, so I write old instead, font way old. The browser's going to be, “I don't know what this is. Whatever, we'll just keep going.” Your thing won't be bold, but it will still be there.

Chris: With JavaScript, if you mistype a variable name or you try to use a property, you try to call a variable that doesn't exist or a myriad of other things happen… your minifier messes up and pulls one line of code to the one before it without a semicolon where it needs one, the whole app crashes. Everything from that line on stop working. Sometimes even stuff that happens before that doesn't complete, depending on how your app is set up. You can very quickly end up with an app that in a different approach, one where you rely a lot more on HTML and CSS, it would work. It might not look exactly right, but it would still work… to one that doesn't work at all.

Chris: There's an argument to be made that in 2020, JavaScript is an integral and important part of the web and most people don't disable it and most people are using devices that can actually handle modern JavaScript. That's true, but that's not the only reason why JavaScript doesn't work right, even if you have a linter there for example and you catch bugs ahead of time and things. There's plenty of reasons why JavaScript can go horribly awry on you. CDNs fail.

Chris: Back in July of last, a year ago this month… at least, when we're recording this… a bad deploy took down Cloudflare. Interestingly as we're recording this, I think a week or two ago, Cloudflare had another massive outage that broke a whole bunch of things, which is not a knock on Cloudflare. They're an incredibly important service that powers a ton of the web. But CDNs do sometimes go down. They are a provider used by 10% of Fortune 1,000 companies. If your JS is served by that CDN and it breaks, the JavaScript file never loads. And if your content is dependent on that JS, your users get nothing instead of getting something just not styled the way you'd like.

Chris: Firewalls and ad blockers get overly aggressive with what they block. I used to work at a company that had a JavaScript white list because they were extremely security conscious, they worked with some government contract stuff. They had a list of allowed JavaScript, and if your site or if your URL wasn't part of that, no JavaScript. You have these sites. I remember going to a site where it had one of the hamburger kind of style menus on every view whether it was desktop or mobile, and I could not access any page other than the homepage because no JavaScript, no hamburger, that was it.

Chris: Sometimes connections just timeout for reasons. Either the file takes a while or someone's in a spotty or slow connection. Ian Feather, an engineer at BuzzFeed, shared that about 1% of requests for JavaScript on the site fail which is 13 million requests a month. Or it was last year, it's probably even more now. That's a lot of failed JavaScript. People commuting go through tunnels and lose the internet. There's just all sorts of reasons why JavaScript can fail and when it does, it's so catastrophic.

Chris: And so we built this web that should be faster than ever. It's 2020, 5G is starting to become a thing. I thought 4G was amazing. 4G is about as fast as my home wifi network. 5G is even faster, which is just bonkers. Yet somehow, we have websites that are slower and less performant than they were 5 or 10 years ago, and that makes no sense to me. It doesn't have to be that way.

Drew: How do we get out of this mess, Chris?

Chris: Great question. I want to be really clear. I know I've hammered on this a couple times. I'm not saying all the new stuff is bad, never use it. But what I do want to encourage is a little bit more thoughtfulness about how we build for the web.

Chris: I think the overlying theme here is that old doesn't mean obsolete. It doesn't mean never embrace new stuff, but don't be so quick to just jump on all the shiny new stuff just because it's there. I know it's one of the things that keeps this industry really exciting and makes it fun to work in, there's always something new to learn. But when you pick these new things, do it because it's the right tool for the job and not just because it's the shiny new thing.

克里斯：我們沒有像我希望的那樣深入的另一件事，但我認為非常重要的是，該平台在過去幾年中已經以非常大的方式趕上了。 盡可能多地接受這一點將為人們帶來更快、更不脆弱、更容易構建和維護的 Web 體驗，因為它需要更少的依賴項，例如使用瀏覽器提供給你的東西-盒子。 我們曾經需要 jQuery 來選擇類之類的東西。 現在瀏覽器有本地方法來做到這一點。 人們喜歡 JSX，因為它允許您以更無縫的方式在 JavaScript 中編寫 HTML。 但是我們在 Vanilla JavaScript 中也有模板文字，可以讓您在沒有額外依賴的情況下獲得同樣程度的易用性。 HTML 本身現在可以取代很多過去需要 JavaScript 的東西，這絕對是驚人的。

克里斯：我們談了一點……這是一個 CSS 的東西，但懸停在鏈接上，以及過去如何需要 JavaScript。 但是使用細節和摘要元素之類的東西，您可以創建披露，例如展開和折疊或手風琴元素，無需腳本。 你可以只用一個……我不應該說只是，我討厭這個詞來自動完成輸入。 但是使用一個不起眼的輸入元素，然後使用一個與之關聯的數據列表元素，並帶有一些選項。 如果您對 vanillajstoolkit.com 上的這些東西如何工作感到好奇，我有一堆該平台為您提供的 JavaScript 東西。 但是我也有一些過去需要 JavaScript，如果你想要一些代碼示例來配合它，現在也沒有一些有趣的東西。

Chris：在 CSS 方面，我最流行的 Vanilla JS 插件是這個庫，它可以讓你動畫向下滾動到錨鏈接。 它非常大。 這是我寫過的最難的一段代碼。 而現在它完全被單行 CSS 取代，滾動行為流暢。 它的性能更高。 寫起來更容易。 修改其行為更容易。 這只是一個更好的整體解決方案。

克里斯：我希望我們做得更多的另一件事是依靠多頁應用程序。 我覺得這裡有點被證明是正確的，因為我最近看到谷歌某人的一篇文章現在實際上也在推動這種方法。 我認為這很有趣，考慮到這個巨大的角度和框架......所有的事情，繁榮，谷歌幾年前開始的。 看到他們回來做這件事真是太酷了。 使用靜態站點生成器和 Netlify 和 CDN 緩存等很棒的服務，您可以為使用單個 HTML 文件的用戶創建令人難以置信的快速 Web 體驗。 所以有點依賴一些開箱即用的東西。

Chris：在這對你來說不現實的情況下，你確實需要更多的 JavaScript，你確實需要某種庫，也許首先看看更小、更模塊化的方法，而不是僅僅為行業的龐然大物而努力。 Preact 可以代替 React 嗎？ 而不是 Angular ......我的意思是，而不是 Vue，Alpine JS 會工作嗎？ 還有一個非常有趣的預編譯器，現在稱為 Svelt，它為您提供類似框架的體驗，然後將您的所有代碼編譯成 Vanilla JavaScript。 所以你會得到這些非常小的捆綁包，裡面只有你需要的東西，沒有別的。 除了 CSS 和 JavaScript，你能不能插入一些第三方 CSS linter 來比較你的 HTML 和你的 CSS，然後把那些不小心留在裡面的東西取出來？ 是否可以採用不同的方式來創作 CSS，例如 Nicole Sullivan 的面向對象的 CSS？ 我們並沒有真正談論這個，但人們應該看看這是一件非常酷的事情。

克里斯：然後我認為也許是第三個也是最重要的部分，儘管它不是一種具體的方法，而更多的是我希望更多人記住的一件事，那就是網絡適合每個人。 我們今天使用的許多工具都適用於擁有良好互聯網連接和強大設備的人。 但它們不適用於使用舊設備、互聯網連接不穩定的人。 這不僅僅是發展中地區的人。 這也是英國人，在美國某些地區，我們的互聯網連接絕對糟糕透頂。 我們國家中部的互聯網速度非常慢。 我知道在倫敦的某些地方，由於歷史原因，他們無法連接新的寬帶，所以你只剩下這些非常糟糕的舊互聯網連接。 全世界都有這樣的地方。 上次我在意大利，同樣的事情。 那裡的互聯網太可怕了。 我不知道從那以後它是否改變了。

克里斯：我們今天建造的東西並不總是對每個人都有效，這太糟糕了。 因為網絡的願景，我喜歡它的一點是，它是一個絕對適合所有人的平台。

Drew：如果聽眾想了解更多關於這種方法的信息，您已經在《精益網絡》一書中詳細介紹了它。 這可以在線獲得。 是實體書還是數字書？

克里斯：兩者兼而有之。 嗯，不。 這絕對不是實體書。 你去leanweb.dev。 您可以在線免費閱讀整本書。 如果你願意，你也可以，有 EPUB 和 PDF 版本，只需很少的錢，我現在忘記了多少錢。 我有一段時間沒看它了。 如果您願意，整個過程都是免費的。 您還可以觀看有關此主題的演講，如果您願意，我將在其中詳細介紹。

克里斯：但我還在 gomakethings.com/smashingpodcast 上為 Smashing Podcast 的聽眾準備了一個特別頁面，因為我在命名事物方面很有創意。 除了本書之外，這還包括大量資源，圍繞著我們今天討論的內容。 它鏈接到我們涵蓋的許多不同技術，我寫的其他文章更深入地探討了其中一些主題並稍微擴展了我的想法。 如果人們想了解更多信息，那可能是最好的起點。

德魯：太棒了。 謝謝你。 我一直在學習精益網絡。 克里斯，你最近在學習什麼？

克里斯：是的，有幾件事。 我早些時候在觀看 Jeremy 關於漸進式網絡應用程序的視頻時提到了這一點。 幾年來，我一直在推遲學習如何真正編寫自己的漸進式 Web 應用程序，因為我對正在使用的任何東西沒有特別的需求。 我最近從我在南非的一位學生那裡得知，他們一直在處理輪流停電，因為那裡發生了一些事情。 結果，她無法參與我們經常一起做的一些項目，因為停電了，她無法訪問學習門戶並繼續跟進。

克里斯：對我來說，現在建立一種即使有人沒有互聯網也能發揮作用的體驗比……我意識到也許以前是這樣，所以我開始深入研究，希望把它放在一起接下來的幾週。 走著瞧。 Jeremy Keith 在這方面的資源絕對是救命稻草。 我很高興他們存在。

克里斯：我知道，德魯，你提到你喜歡問這個問題的原因之一是為了表明人們無論多麼老練，總是在學習。 只是一個相關的軼事。 我想我一直是一名網絡開發人員，大約有八年了。 我仍然必須谷歌使用 CSS 屬性來製作斜體，實際上每次我使用它時。 出於某種原因，我的大腦默認使用文本裝飾，即使那不是正確的。 我會嘗試幾種不同事物的組合，每次我總是有一個詞錯。 我有時也寫斜體而不是斜體。 是的。 如果有人曾經覺得，哦，我永遠不會學習這些東西......只要知道無論你多麼老練，總有一些非常基本的東西你一遍又一遍地谷歌。

Drew：我已經做了 22、23 年的 Web 開發人員，但我仍然每次都必須在 Google 上搜索 Flexbox 的不同屬性。 雖然我已經使用了 23 年。 但是，是的，有些事情只是……隨著年齡的增長，可能會有更多的事情發生。

克里斯：是的。 老實說，我最終建立了一個完整的網站，我一遍又一遍地用谷歌搜索，只是為了更容易複製粘貼參考，因為這比谷歌搜索更容易。

德魯：這不是一個壞主意。

克里斯：我就是那種懶惰的人。 我將建立一個完整的網站來拯救自己，就像三秒鐘的谷歌搜索一樣。

Drew：如果您的聽眾想從 Chris 那裡聽到更多信息，您可以在網上找到他的書：leanweb.dev，以及他的開發者 Tips 時事通訊和更多信息，請訪問 gomakethings.com。 克里斯在推特上的克里斯費迪南迪。 您可以在 vanillajspodcast.com 或您通常獲得播客的任何地方查看他的播客。 感謝您今天加入我們，克里斯。 你有什麼離別詞嗎？

克里斯：不。非常感謝你邀請我，德魯。 我有一個絕對粉碎的時間。 這很有趣。 我真的很感激有機會來聊天。