Jeremy Wagner 的 Smashing Podcast 第 45 集：什麼是負責任的 JavaScript？

這一集得到了我們在 Wix 的親愛的朋友的大力支持，Wix 是專業人士建立客戶網站、管理複雜項目和在線發展業務的平台。 謝謝！

在這一集中，我們將討論負責任的 JavaScript。 代碼負責意味著什麼，我們應該如何以不同的方式處理項目？ 我與專家傑里米·瓦格納（Jeremy Wagner）進行了交談以找出答案。

顯示註釋

• 負責任的 JavaScript 網站
• 從 A Book Apart 購買這本書
• 傑里米的個人網站
• 傑里米在推特上

每週更新

• 史蒂文·胡伯 (Steven Hoober) 所寫的接觸時代的菲茨定律
• 網頁設計做得很好：Frederick O'Brien 寫的完全沒有意義
• Nick Babich 和 Gleb Kuznetsov 編寫的關於創建語音用戶界面的一切你想知道的事情
• WordPress 加入由 Leonardo Losoviz 編寫的塊協議的意義
• Knut Melvar 寫的關於 Markdown 的思考

成績單

Drew McLellan：他是一名技術作家、網絡性能書呆子、開發人員和演講者，目前在 Google 工作。 他為 A List Apart、CSS-Tricks 和 Smashing Magazine 撰寫文章，並且是新書名“Responsible JavaScript for A Book Apart”的作者。 所以我們知道他是一位熟練的技術人員和溝通者，但你知道他想在立式槳板上環遊地球嗎？ 我的好朋友們，請歡迎杰里米·瓦格納。 嗨，傑里米，你好嗎？

傑里米·瓦格納：我太棒了。 你好嗎？

德魯：我很好。 謝謝你。 今天我想和你談談負責任的 JavaScript 的想法。 這是某種新的方法或技術，還是您實際上是在談論負責任地使用 JavaScript？

Jeremy：我實際上是在談論負責任地使用 JavaScript。 因此，根據 HTTP 存檔，我們看到去年移動設備下載的 JavaScript 量中位數增加了近 58%，從大約 290 KB 增加到近 500 KB。

德魯：哇。

Jeremy：所以當我談到負責任地使用 JavaScript 時，它是一種用戶至上的方法，可以說……批判性地評估我們正在構建的內容以及我們正在構建的目標是現代 Web 開發實踐所服務的目標，所以說話。 而且我想這有點……也許不是開玩笑，但我並沒有對現代 Web 開發進行抨擊，但現代 Web 開發的一個副產品是向項目添加依賴項非常容易。 一切都是 MPM 安裝，每個 MPM 安裝都有成本，成本各不相同。 但我們確實看到的是，在 HTTP 存檔數據中，第 95 個百分位……意味著 5% 的體驗是最慢的……或者不是最慢的，但交付的 JavaScript 最多，在去年增加了約 875千字節到大約 1.4 兆字節。

德魯：哇。

Jeremy：所以它是大量的 JavaScript 被傳輸，它對加載性能和運行時性能都有影響。

德魯：所以你提到了那裡的表現。 在我看來，現代網絡體驗就像 10% 的 HTML 和 CSS 以及 90% 的 JavaScript。 並且必須有某種性能考慮。 我的意思是，你談到了我們正在傳輸的數據量，但還有其他性能考慮因素，因為有很多 JavaScript。

傑里米：對。 因此，互聯網連接速度很慢，您知道……我住在美國的哪個地方，如果您在大城市以外的地方走得足夠遠，則取決於去哪裡，這會變得有點困難……僅應對互聯網的速度有多慢有點像這些農村地區，並且對生活在這樣的地區的人們很重要。 因此，當您開始交付數兆字節的 JavaScript 時，它的加載性能方面已經具有足夠的挑戰性，但您也可能正在與沒有 iPhone 的人打交道……比如 iPhone X 或 iPhone 13。

傑里米：他們可能只是在功能手機上，或者只是有點像廉價的 Android 手機，只是試圖在生活中導航。 我的意思是，想想諸如網上銀行、失業援助或其他政府援助之類的東西，諸如此類的應用程序門戶。 在線學習，在很多地方，過多的 JavaScript 確實會對那些可能沒有足夠幸運生活在大都市地區甚至沒有寬帶互聯網服務的都市地區以及使用速度較慢的設備的人產生不利影響. 我有點認為作為開發人員，我們有這種傾向……我們購買 MacBook 或這些高端設備，但有時我們並沒有真正看到當我們過度使用 JavaScript 時這些問題會出現在哪裡。

德魯：就像你在那裡提到的那樣，有時是那些因無法訪問服務而遭受最大損失的個人會受到此類事情的懲罰。 那些沒有快速數據連接或沒有功能強大的設備的人有時會訪問對他們來說意味著一切的服務……這對他們來說意味著他們能夠訪問的一切。 所以它在某些方面幾乎成了一個人權問題。

傑里米：是的。 我的意思是，我們傾向於看到 Web 性能以商業價值為框架。 我是一些電子商務公司的績效顧問，就像一家大型食品公司，一家大型電子商務公司……就像一家商店，一家電子產品店，這樣做很誘人，對吧？ 因為當你為一家企業工作時，我的意思是，顯然你希望財務狀況良好，而我認為網絡性能確實在其中發揮了作用。 我認為有許多案例研究證明了這一點。 然而，有人性的方面，甚至對於企業來說，比如雜貨店之類的東西。 是的，他們是收入驅動的。 他們希望擁有健康的財務狀況，因此 Web 性能是其中的一部分，但他們也在滿足關鍵需求，對吧？ 就像你必須吃飯，對吧？

傑里米：就像有些人可能出於某種原因回家一樣。 他們可能無法輕易上車。 他們可能沒有車。 因此，他們依靠這些服務來獲得生計，但更重要的是，如果他們需要幫助，尤其是危機干預之類的事情，他們會得到幫助。 我不認為說一個被虐待並被趕出家門的伴侶可能會轉向他們的智能手機，並點擊谷歌試圖找到一個危機干預和援助的門戶網站，這並不是很牽強。 而 JavaScript 可能會妨礙這些類型的目標並滿足人類的需求。 當我們傾向於過度依賴它時。

德魯：我的意思是，在過去 18 個月左右的時間裡，我們已經看到了這種情況的一瞥，因為 COVID 和人們進入隔離狀態，正如你所說，需要訂購要交付的雜貨。 那時，網絡成為他們的生命線。 他們感覺不舒服，無法離開住處，因為他們正在隔離，他們必須得到食物，他們必須得到必需品。 所以，是的，我認為，對於我們所有人來說，它是日常生活中越來越重要的一部分。

傑里米：沒錯。 回到那種設備故事，Tim Kadlec 幾年前寫了一篇很棒的文章，我想那是兩年前，也許是三年前，但它被稱為優先考慮性能的長尾。 當你看到那個......所以用網絡性能術語來說，我們有點談論實驗室數據與現場數據。 實驗室數據就像您在運行燈塔或在網頁測試中投放網站以查看其運行情況。 這些都是非常有用的工具，但是當您查看這些現場數據時，您真的開始獲得更大的圖景，並更深入地了解您的受眾到底是誰。 在這篇文章中，Tim Kadlec 談到了優先考慮性能的長尾意味著什麼。 這意味著所有這些設備……可能不如我們開發人員可能擁有的設備那麼強大和強大。

傑里米：那篇文章背後的想法是，如果我們能夠專注於 90% 或 95% 的人……並改善這些人的體驗，我們正在為每個人構建一個更快的網絡，包括那些使用快速設備的人。 並攻擊美國的一個數據點，這就像 statcounter.com 一樣。 大約 28 點……大約 28% 的人使用的是該工具捕獲的 iOS 設備。 其中大約 21% 是安卓系統。 Android 往往代表了設備長尾中的很大一部分，因為 Android 不是單一的。 多家設備製造商生產 Android 手機，但與世界形成對比，因為世界不僅僅是美國，大約 16% 的人使用 iOS，大約 41% 的人使用 Android。 因此，優先考慮那些較慢或可能較慢的體驗確實值得。

德魯：我在你的書中讀到了關於設備熱節流的內容，這在我之前從未真正考慮過。 有什麼顧慮？

傑里米：那裡的擔憂，無論如何我都不像微處理器專家。 我只是一個可能寫得有點多的網絡開發人員，但是......所以熱節流背後的想法存在於所有系統中，不僅僅是手機和平板電腦，是微處理器將......當它承擔過多的工作負載或實際上只是一般的工作量，這項工作的廢物是熱量。 所以設備有辦法緩解這種情況。 就像您的筆記本電腦同時具有被動和主動冷卻設備一樣。

傑里米：所以就像一個被動冷卻設備就像一個散熱器或某種散熱器。 而它的活躍部分就像一個風扇，可以更有效地散熱。 一些像定制 PC 構建可能會使用像液體冷卻，這是一個比較極端的例子，但手機沒有這個，因為如果便攜性是你的一種，你將在哪裡真正適合風扇東西，對吧？

Jeremy：所以為了讓這些設備應對這些繁重的工作負載，他們可能會人為地降低處理器的速度，比如降低時鐘頻率，直到設備進入可以提高時鐘頻率的狀態。 這會產生影響，因為如果你正在咀嚼大量的 JavaScript，你就會像這些大塊一樣從網絡上下來，這會開始處理，對嗎？ 因此，在編譯和執行中通過評估和解析進行了大量處理。 如果你用 1 兆字節或 2 兆字節的 JavaScript 來做這件事，並且你有很多其他進程在後台運行，比如不同的選項卡，那種類型的東西，可以讓你的狀態......設備可能會進入熱節流狀態，這意味著它將無法承擔額外的工作。

德魯：所以這是一種負反饋循環。 不是嗎？ 你讓設備做很多工作。 它變得非常熱，然後實際上執行該工作的能力降低，因為它不得不節流。

傑里米：對。 再說一次，我不是微處理器專家。 我敢肯定，如果一位非常熟悉這一點的工程師可能會糾正我的一些細節，但總的想法是，是的，隨著環境壓力的增加，該設備不太能夠應對這些繁重的工作量，直到壓力降低。

Drew：所以我們正在為最新的 Apple M1 Max 的各種設備編寫 JavaScript，這是新的處理器，不是嗎？ 從筆記本電腦一直到幾乎沒有足夠的工作 RAM 來呈現網頁的設備。 但網絡並不是這樣開始的，年輕的聽眾可能有興趣知道我們過去完全不用任何 JavaScript 來構建交互式網絡體驗。 我們龐大而沉重的框架將成為我們的毀滅。

Jeremy：我想說框架是有時間和地點的，那些讀過這本書節選的人可能會認為我是反框架的。 我肯定對幾個框架持批評態度，但它們確實是有目的的，並且可以以保持良好用戶體驗或可以帶來良好用戶體驗的方式使用它們。 但我認為我們做的還不夠多，就是根據它們如何損害……運行時性能來批判性地評估這些框架，對吧？ 所以我正在談論的東西類型，如果你點擊一個按鈕，設備需要大約一秒鐘或者兩秒鐘來響應那個輸入，因為在後台發生了很多事情。 你有第三方 JavaScript 東西，比如收集分析，然後你有其他東西在線程上運行。

Jeremy：如果你不嚴格評估框架的運行時性能，你可能會留下一些機會來更好地為你的用戶服務。 所以一個很好的例子，我總是喜歡使用 react 與 pre-act。 我一直在敲這個鼓有一段時間了。 不久前，我為 CSS-Tricks 寫了一篇文章，描述了一個基本的點擊交互，比如移動導航菜單。 這聽起來微不足道，但您會發現，在所有設備上，React 提供了更好的運行時性能，但它具有基本相同的 API。 有一些差異，有一些細微的差異和東西可以用預演兼容來掩蓋，但是很簡單……我不應該說一個簡單的選擇，但是那個選擇，那個基本的選擇可能是體驗之間的差異這對所有用戶或至少對大多數用戶都非常有效，或者只對某些用戶有效。 希望這有點道理。]

Drew：我的意思是，有了所有的框架和構建工具，他們似乎一直在做一些事情，比如搖樹和優化他們發布的包以及如何將它們交付給瀏覽器。 在使用大型框架時，您是否認為自己正在編寫如此龐大的應用程序，以及您自己的代碼如此之多，以至於框架由於其所有抽象性而使您能夠交付更少的代碼？

傑里米：這是一個很難回答的問題。 一方面是框架本身代表了您永遠無法優化的大量代碼。 因此，擁有一個精簡的框架，比如 pre-act 或任何數量的類似......或者像拼寫一樣，這很有幫助。 但我看到的問題是，我認為來自 HTTP 存檔的數據支持這一點是，似乎每當我們在微處理器和網絡方面取得這些進步時，我們都傾向於消耗這種收益，對嗎？

傑里米：我們往往只是在這台跑步機上，我們從來沒有真正進步過。 而且我不知道，就像我對……的歷史沒有千里眼，或者對不起，框架的未來是什麼樣的。 我確信可以收集到一些效率收益。 但是我們在該領域看到的原始 JavaScript 的數量……只是使用了原始 JavaScript 的數量。 並沒有告訴我這是一個我們可以自動化解決的問題。 我認為我們必須……我們必須成為人類，進行干預並做出符合用戶最大利益的決定。 否則，我看不到我們離開跑步機，也許在我的職業生涯中，但我不知道。

Drew：在書中，您談到了網站和 Web 應用程序，以及了解差異以及您正在使用的應用程序如何幫助您選擇開發和優化策略。 告訴我們一點。

傑里米：這是一個非常好的問題。 我在我為 A List Apart 撰寫的同名文章中寫到了這一點，名為“負責任的 JavaScript 第 1 部分”，這是本書的前奏。 是不是我們在這個術語中加載了很多東西。 就像作為一名技術作家一樣，我看到兩者可以互換使用。 我看到的是網站，這意味著它是一種多年齡的體驗，對吧？ 它是文檔的集合。 現在是一個文檔……這些文檔可能嵌入了這些小島之類的功能，就像最近的術語一樣，這些功能小島可以讓人們完成工作。

傑里米：但是還有像網絡應用程序和網絡應用程序有點像功能這樣的原生應用程序的內涵。 所以我們談論的是單頁應用程序，我們談論的是大量的 JavaScript 來驅動複雜的交互性。 有時網絡應用程序模型是有意義的。 例如，Spotify 就是一個很好的例子。 這作為一個網絡應用程序效果更好。 您不會真的想嘗試使用它或將其設計為多頁應用程序。 就像一個傳統的網站，但我認為這不是一個可持續的默認設置，因為當你對每個項目的默認設置是，“好吧，我們只需要發布一個單頁應用程序，比如客戶端路由器和重型框架，然後卸載所有這種從服務器渲染到客戶端的處理過程。” 我認為這就是您開始達到將用戶排除在外的地步，儘管是無意的，但仍然排除了他們。

德魯：有沒有很大的鴻溝，你認為採取我們將發布一個網站並且它可能具有任何交互功能的人與那些說“我們是一家軟件公司，我們是製作產品、軟件產品和我們將通過 Web 交付它的平台，而不是用於多個平台的本地應用程序。” 他們是否有可能以完全不同的方式解決問題？ 考慮因素是否因您當時的觀點而異？

傑里米：這是一個棘手的問題。 所以-

德魯：我很難說。

傑里米：我會說一家公司……這樣一個很好的例子就像新聞一樣，對吧？ 這種網站模型很好地服務於它們，因為它實際上是文檔、文章的集合。 開發這些體驗的人可能會擁有不同的技能組合，而不是像 Spotify 這樣的公司或擁有像 Envision 這樣的大型 Web 應用程序或類似事物的公司。 所以，是的，我認為他們會從不同的角度來解決這個問題。 我看待它的方式是有一個細分市場……或者至少這是我對整個 Web 開發社區的看法，即有一部分人，來自非傳統軟件開發的 Web 開發人員背景，對吧？ 我就是這些人中的一員，當我還是個孩子的時候，我正在修補網絡，對吧？

傑里米：就像在中學時一樣，為所有人做愚蠢的粉絲頁面，就像我當時真正喜歡的電子遊戲一樣。 而且我從未接受過那種計算機科學教育。 在此過程中，我學到了一些計算機科學概念。 然後還有一部分開發人員，尤其是我認為在過去 5 到 10 年出現的開發人員，他們以更加面向計算機科學的方式來處理這個問題。 而且我認為這將……這些差異和經驗將引導每個小組就如何最好地為網絡開發得出自己的結論。 但我認為，你真正能夠……為網絡進行可持續開發的唯一方法是批判性地評估你正在構建的內容，並嘗試圍繞最能為這些產品的用戶服務的方法進行調整。 當我評估這些東西時，這就是網站和網絡應用程序模型在我腦海中的位置。

德魯：是的。 很有趣。 我的意思是，在書中，你實際上引用了我的一些工作。 非常感謝。 我選擇的枯燥技術基本上是 PHP Apache 和少量的手工 JavaScript，默認情況下可以創建非常快速的用戶體驗，而無需進行任何特定的優化。 我認為這為來到網站上查看內容的前端訪問者提供了良好的用戶體驗。

Drew：但實際上，一旦您登錄並在網站上發佈內容，我覺得創作內容的環境有點相反。 我認為它是用網站方法構建的，而不是一種更重的 JavaScript 重 Web 應用程序方法，以至於我在想……或者它可能需要兩者兼而有之。 我需要繼續以漂亮的靜態 HTML 和 CSS 以及少量 JavaScript 發布前端。 但是我想提供內容創作體驗的後端可能是不同的技術選擇會更好。 這很有趣，因為它並不總是必須是一件事或另一件事嗎？ 這不是二元選擇。 這更像是一個頻譜，你會說嗎？

傑里米：是的，絕對的。 我認為我們開始在社區中看到更多關於 Web 開發的討論。 對於可能對我的書感興趣的人來說，它肯定來自網站方面。 再一次，因為我覺得這總是一個很好的默認值。 如果您不知道要如何構建某些東西，最好嘗試以一種盡量減少 JavaScript 使用並儘量減少向客戶端推送更多工作的方式來構建它。 也就是說，我認為註意到是一種極好的體驗。 我認為這些久經考驗的、真正“無聊”的技術非常適合手頭的任務。 它以一種對開發人員開放和支持的方式這樣做，對嗎？

Jeremy：你不需要對狀態管理存儲或狀態管理框架有深入的了解，才能真正完成這些事情。 我認為這種特殊方法很好地服務了這一點。 但就您的觀點而言，我認為任何網站都有機會更接近頻譜的中間位置，而無需全力以赴所有客戶端路由，例如管理客戶端上所有內容的重型框架和此類事物。 我認為該島的方法正在開始探索它的樣子。 我承認，我可能無意中做了一些島嶼類型的事情。 我想我們已經有很長一段時間了，只是還沒有真正命名它。 但我認為，既然我們已經確定了這可能是一個中點，我們可能會開始看到提供良好用戶體驗的 Web 體驗，但仍然更具交互性。 希望這不是非常曲折。

Drew：這有點回到我們嵌入 Flash 島的日子，或者——

傑里米：是的。

德魯：頁面中有一些東西，這是我們的小互動部分，其餘部分在流動。

傑里米：是的，就像 Flash 一樣，我的天啊，我大學畢業後個人作品集的三個迭代對於高級 Flash 仿冒品和懸停效果來說真的很糟糕。 那東西真的，真的很有趣。 我有時會想念它，因為我們不再使用 Flash，所以有大量內容即將消失。 這真的很糟糕，但在某種程度上，它是我們正在談論的這種島嶼事物的先驅。 你可以只擁有一個靜態網頁和所有東西，但是你會擁有這種非常豐富的交互體驗，就像在它中間撲通一聲。

Drew：長期以來，漸進式增強一直被認為是構建 Web 體驗的最佳實踐方式。 你覺得現在還是這樣嗎？

Jeremy：我會承認它可能......我不會承認做漸進式增強需要更多的工作，因為在某種程度上，你有點分裂你的開發經驗。 您正在嘗試以服務器可以處理類似於這些關鍵交互的方式提供網站的最小可行功能。 但除此之外，你會說，“好吧，現在我想促進這種交互，讓 JavaScript 更流暢一點。” 我仍然認為這是一種通過網站、應用程序或產品實現目標的可行方式。

Jeremy：但我要說的是，我絕不會建議網站上的每一次交互都必須通過這種同步導航類型的模式來促進。 因此，一個很好的例子可能是您的經濟網站的結帳頁面肯定應該有一個服務器路由。 你應該有一個服務器路由來將東西添加到購物車，然後你應該能夠撒上足夠多的 JavaScript 來讓它更令人愉快，這樣事情就可以更快一點，更異步。

德魯：在衡量績效方面。 我們聽到了很多關於核心網絡生命力的信息，主要來自谷歌。 這些真的是我們應該衡量的基準嗎？ 或者這正是谷歌想讓我們這麼想的？ 我現在意識到這可能是您開始在 Google 工作時遇到的一個難題。

傑里米：是的，是的。 你知道，所以我在這里為自己說話。 我認為 Web Vitals 是……最初的核心 Web Vitals 是一個很好的嘗試來定義用戶體驗的哪些部分是重要的。 我確實認為諸如累積佈局變化和最大內容繪製等指標開始以我們還沒有開始量化的方式思考體驗。 在特別累積的佈局轉變之前，因為如果曾經有過讓您憤怒的點擊的時刻，那是因為按鈕喜歡在頁面上移動或其他東西。 我的意思是，我認為這對衡量它很有幫助。 這是不完美的。 而且我認為任何從事核心網絡生命體徵的人都會同意其中一些指標需要改進。 還有其他指標我不一定完全同意。 就像第一個輸入延遲是一個很難確定的指標。

傑里米：我認為它真的很有用，對吧？ 因為你的字面意思是我們想要測量用戶第一次交互的延遲和交互性，但它確實缺乏一點上下文，對吧？ 因為有些……很多事情都會影響它，因為它不一定總是與 JavaScript 相關聯。 第一次輸入延遲可能代表聚焦表單字段所產生的延遲，對吧？ 那種東西，HTML 中的東西。 我認為這些指標……諸如首次輸入延遲之類的指標可能是……如果您可以將它們與諸如長任務 API 中的條目、元素計時和這些類型的事物等內容關聯起來，它們將是有益的。 我最終認為核心 Web Vitals 的未來將證明它將有助於衡量什麼是良好的用戶體驗。 那是我個人的看法。

德魯：我想是的，這是你可以隨時衡量自己的事情之一，衡量你自己的進步，或者如果你的分數發生變化，你的體驗是否會變得更糟，不太關心交通信號燈，而是關心你所知道的關於您網站的背景以及更改如何帶來改進。

Jeremy：我認為累積佈局偏移等指標非常好，但它們也可以從一點點改進中受益。 就目前而言，累積佈局偏移主要衡量加載期間發生的佈局偏移。 正如我們所知，當用戶訪問頁面並登陸頁面時，佈局變化可能隨時發生，對吧？ 所以我認為肯定有工作可以改善我們觀察這種現象的方式，當然。

Drew：我認為佈局穩定性是在使用漸進增強時實際上更難實現的事情之一。 有時，當您加載服務器呈現的頁面然後開始在客戶端中對其進行增強時，可能會產生這種佈局變化的危險，不是嗎？

傑里米：當然。 這就是組件的水合變得有點棘手的地方，因為該組件的尺寸可能由於多種原因而發生變化。 就像客戶端組件中存在的內容可能不會在服務器上呈現，因為在客戶端執行之前不會評估狀態。 這是一個極其困難的問題。 我不會坐在這裡假裝我喜歡它的靈丹妙藥。

Drew：我想談一談動態導入和代碼拆分，這兩種技術都是解決在體驗開始時預先下載和執行大量 JavaScript 的問題的不同技術。 通過提出大量小請求是否存在過度優化的風險，尤其是在最簡單的小型項目上，或者從一開始就預先確定您將遇到這些問題，它們是否絕對沒有害處？ 還是應該等到真正看到性能問題後再考慮這些事情？

傑里米：所以我建議你剛才所說的結尾是一個很好的引導方式。 我們不應該嘗試過早地進行優化，除非這些優化當然可以非常快速和輕鬆地實現，但是如果在早期需要大量的努力來優化，當沒有很多性能問題時，我會爭辯說代碼拆分可能是不必發生的事情。 您可能只需預先加載該功能。

傑里米：但是例如，我在書中談到了這個。 如果你有一個由一大段 JavaScript 驅動的高價值交互，對我來說，一大段 JavaScript 可能意味著 20 KB，因為在經過壓縮的線路上，最終可能是 60 KB 的 JavaScript 塊。 然後，如果您可以在主捆綁包或無數捆綁包中的任何一個中提取它，您的網站可能正在發貨，您將有助於啟動性能。

Jeremy：但在書中，我討論了一種關於感知何時……或者至少嘗試感知用戶何時可能進行高價值交互的技術。 所以我使用的例子是一段 JavaScript。 它用於驗證表單的內容，因為 HTML 表單驗證很棒，但它也不是樣式化的，而且非常簡單。 對於諸如類型等於電子郵件之類的事情沒有很大的靈活性，對嗎？ 它以某種方式對其進行評估。 但是，在客戶端驗證表單確實很有幫助，因為我們也可以設置它的樣式。 我們可以調整該驗證的外觀，使其更接近品牌美學或網站美學。 所以在這個例子中，我所做的是，如果用戶關注……甚至只是關注表單中的任何字段，這就是我們預加載那段 JavaScript 的點。

傑里米：所以希望到那時，我希望因為填寫表格需要一點時間，網絡有足夠的時間將其拉下來，以便在調用動態導入時，它可以將現金打到獲取已經預加載的內容。 這是我一直在這里和那裡進行的一些工作，而且在所有情況下都很難做到。 例如，您不能在懸停時始終可靠地執行此操作，因為某些設備沒有精細的指針。 他們有……他們是……這是點擊輸入，對吧？ 例如，懸停發生的時間與您有一個細指針的時間不同。

Drew: One aspect of responsible JavaScript use is thinking about how we consume our users, available resources, be that sort of battery life or data allowance, if they're on a data plan. Are there techniques that we can lean on here to, to help us think about those things?

Jeremy: Yeah. So currently, or at least historically from the last… I don't know exactly when this feature shipped but Chrome for Android and there used to be a Chrome extension thing for this called Save Data. And what you would do is if in your settings, in Chrome for Android you would say, “Reduce data usage.” I forget exactly what the label is on the check box, but you check it, you turn it on and what that does is it sends this signal as a request header. And it's a request header that's called save data and it only has one token and it's just on. Because if it's off, the header just doesn't get sent. And you can… on the backend, at least, you can look at this header and you can decided, “Well, do I really need to send the styles and the JavaScript for this carousel or can I render this differently?

Jeremy: Or maybe you start thinking about stuff outside of JavaScript where maybe you send lower quality images. There's a lot of opportunities there to reduce data usage. This is evolving though, save data is still around. And I think it will be for the foreseeable future, but now we're converging on a media query called prefers reduced data. So we have stuff like prefers reduced motion, prefers color scheme, it's sort of in that vein where I anticipate that these will be operating system level settings that we can make to say, “I really want websites or apps to use less data with this signal.” And you can match it on the client side, with the prefers reduced data media query using match media in JavaScript.

Jeremy: So then you can use that in JavaScript to say, “maybe this functionality isn't the most important thing. Maybe we don't really need to load this associated video embed if the text serves the purpose.” That type of thing, but it also converges with the save data header, at least this is what I observed is when I turn on the save data feature in Chrome for Android, the prefers reduce dat: reduced media query matches, but it also sends save data so you can still act on this on the back end or the front end.

Drew: That's nice. So in a sort of app context, you might feel.. rendering a big data table, you might only return some very key columns. Out of that, the most commonly referenced, rather than the full data and really sort of reduce the amount of that's sent over the wire.

Jeremy: Right. Or you might say… you might pull APIs less frequently in JavaScript, that type of thing. It's kind of a hack need phrase, but it really is limited to your imagination. There's a huge space where I think that concept can be applied to deliver better user experiences. And I've used it with a client of mine in Wisconsin. In rural Wisconsin it's just like… it is an internet dead zone. Like it's so difficult to… I don't know how people cope with how slow it is. Maybe it's just because of my data plan and I might be roaming or whatever, but I've used this to some effect to say, “You know, maybe they don't need this carousel.” Somebody who's just kind of out there in the sticks who… there's a lot of farmland in Wisconsin, but there's also like a lot of forests and somebody might need some work done in logging, right? It's a logging company. And so maybe all of these images, aren't really crucial to that user experience. And they really just want to get to… the phone number or whatever it is, and they want to get to it as fast as possible.

Drew: One thing many of us do is write JavaScript in sort of new shiny versions of VS script and TypeScript sometimes, and then use build tools to transfer that down to older syntax for browsers that encounter out in the wild. In some ways that feels like an excellent practice because we're building a code base with nice more modern clean code. In the case of TypeScript, perhaps more reliable code, less bugs. But are there consequences of doing this transpilation process that we might need to be aware of?

Jeremy: Anytime you take a new syntax and you have to transform it so that it's more broadly compatible, that's going to generally… I have not done this comprehensive audit of all features, but generally I've observed that, that results in more JavaScript. And that makes sense because for things like default parameters on functions, which are well supported by the way, and probably you can ship… I think you could probably just ship that on transpile and be fine, but it's a good example. When that gets transformed, it has to inject a lot of helper code in the function to look… to evaluate those defaults, right? So you get that equivalent functionality.

Jeremy: Now, JavaScript is evolving all the time and I think for the time being, we're going to be coping with transpilation costs. And it definitely does have an impact. When I worked with an e-com company, we were able to reduce several of their bundles for their pages, anywhere between 10%, maybe even 5%, in some cases, to sometimes 30 or 40% when we used a technique to transpile two sets of bundles, right? I talked about this at smashing comp. The name that got kind of got tacked on it was differential serving where you say, “I'm going to generate these transformed bundles for older browsers and serve it to them.” And I'll generate a different bundle for users on modern browsers or evergreen browsers that will be smaller because there will be less of that transpilation overhead. And when we use that, there was a measurable improvement in the user experience. And there were signals that that engagement was better when we did this. That said, differential serving is an interesting thing because IE11 is kind of now like fading. It's taking time, but it's fading.

Jeremy: But Matt Hobbs who works for the UK government. I think he works on the NHS website. I think, don't quote me on that Matt. But he sent me some data that showed that there was still a fair amount of people who were still on Internet Explorer and not just internet or 11. Like there were some columns or row in this data rather, that showed that some people were still on like IE6 or IE7. And so you have to evaluate when it makes sense to do something like that, because it is a lot of extra work and it takes a lot of effort.

Jeremy: In the case of the NHS or literally any government service, I would say that it's virtually a mandate that you have to preserve a level of functionality that serves literally everybody, because you don't know where they're going to be accessing the web off of, right? The constraints we develop for are incredible, it's really, really hard. It's thousands and thousands of different types of devices and I think it makes a in those cases, but maybe not so much for your regular web app, right? It just depends on what the purpose is.

Drew: So keeping on top of the browsers that you need to support and the features that you need to transpile and keeping your configuration and your build tool up to date is… becomes quite important.

Jeremy: Yeah, for sure. This is sort of the more technical part of how you set up tool chains to do this, but… evaluating what your user base looks like is very important, because if a browser kind of falls out of a certain threshold of usage from significant to relatively insignificant, that might be the point at which you decide to evaluate, “Hey, maybe we need to bump things up in our browser's list configuration, so that we're transpiling bundles to be smaller since we don't need to ship those transforms anymore.” But it is kind of like another added step. And one of the approaches I talk about in the book is that you can write your JavaScript one in a couple ways.

Jeremy: You could decide that your style for using JavaScript will be to rely on older language constructs that are natively well supported. Like I think constant let are supported back to IE11. So it doesn't preclude you from using those types of things, but it allows you to ship less JavaScript. Whereas you… or you could say like the alternate approach might be that you are going to write JavaScript for newer browsers only, and accept that a segment of your users may not have functionality. But again, that depends on the purpose that your website is serving and whether or not it's crucial, right? Or infrastructure.

Drew: The web platform is moving on that at magnificent pace, it seems at the moment and there seem to be all sorts of things being added to CSS. For example, that offer capabilities that we previously have to lean on JavaScript for. It is one way to use JavaScript responsibly to just not use it and to lean on native browser features instead?

Jeremy: I think that also works for JavaScript itself where it makes sense to use an API directly rather than an abstraction of it. Definitely do that. But certainly in the case of HTML and CSS, there are things we can now do or will be able to do in CSS that we just don't need JavaScript for. So an example of this would be… what's the word for it? Truncation of content, right? That's something that we can do in CSS. Whereas I've been in situations or in projects where I've seen libraries or a library get downloaded that does that. And we don't necessarily need to really do that anymore because CSS can handle it.

Jeremy: Or we have access to these layout modes now where we don't really need. If we invest the time to learn these layout modes like grid, we don't really need to fall back on layout libraries to handle these things for us. And we can develop these experiences that are unique. And what's great about that is with layout modes like CSS grid, if they're abstracted, it kind of reduces what you can do with them, because you are only able to take advantage of what the abstraction offers. And if you really want to build some eye-catching layouts that really like push the boundaries of what's possible, I always like to point to Jen Simmons, her experimental layout lab homepage.

Jeremy: I don't know how you would achieve a layout like that if you abstracted it into its own sort of layout library. You almost have to use it… I would think more than almost, you would have to use CSS grid directly in order to accomplish something like that. And that is like zero JavaScript and it's incredible and it's really neat. And I think the web in general would benefit more if we leaned more heavily on CSS and other core web technologies, as much as we do on JavaScript, probably not possible, but one can dream.

Drew: So the book Responsible JavaScript is out now from a book apart. And I really like it, it's full of very practical information. It's very to the point, you know? There's not filler. It's not like reading a recipe online where you have to hear about a trip to Peru before you get to the nitty gritty. It's just like it's all straight in there and it's all very nicely written. Was it a challenge to put that set of information together?

Jeremy: I'll have to ask… if this is the case, but I Think Responsible JavaScript might be the longest book that A Book Apart has put out, but I would have to go and reach into the closet for my copy of a responsible responsive design to see if I beat out Scott Gel on that, because that was a bit of a book, an awesome book, by the way, it was challenging I'm… As your listeners can probably guess I'm sort of a naturally verbose person and, and, and recovering, trying to like be more succinct, but we really packed in as much as we could and kept it as straight to the point while still trying to retain some, some light lively pros. So it didn't like sound mechanical, but the result was that the manuscript is like 42,000 words. So it's a book, it's a chunk of words and we had a great time working on it. People at A Book Apart were fantastic and, and really setting up those guardrails so that we would be successful.

Drew: And it's very much a book that you can sort of dip into various parts. You don't need to read it cover to cover, to gain loads of helpful information. You can just sort of find the bit that's relevant to the problem that you're facing at the moment and dive in there. So I think that's really great about it. So I've been learning all about Responsible JavaScript. And what have you been learning about lately Jeremy?

Jeremy：自從它問世以來，我一直在做的一件事情就是搞亂 CSS 繪製 API。 我真的很喜歡paint API。 我的意思是，它總是以自己的方式存在…… 喜歡以它自己的方式，因為喜歡畫布 2D 上下文已經是一回事了。 因為那......你以前不能動畫和那種類型的東西。

Jeremy：最近我一直在刷新博客。 那就是……我是一個巨大的最終幻想極客，就像我剛剛重播的最終幻想 II 一樣，其中有 15 個，並且某個時候會出現 16 個，但這是一個複古的領域。 所以我一直在使用 CSS 繪製 API 來使用不同的圖塊生成一個隨機的世界。 所以有河流之類的東西，比如穿過草磚和樹木之類的東西。 並對其進行參數化，就像用戶在黑暗模式下訪問我的網站一樣……繪畫作品將呈現為彷彿是夜晚。 它只會有類似的覆蓋層和那種類型的東西。

Jeremy：但是繪畫 API 很棒。 我必須向蒂姆霍爾曼大喊大叫。 他，我在澳大利亞的 JSConf 見過他，他做了一個關於生成藝術的演講。 那真的只是，它真的讓我感興趣。 然後 Sam Richard 在前一天的 CSSConf 上談到了 CSS 繪畫 API，當我把這兩件事放在一起時，就像，“哇，這太酷了。” 所以我實際上做了一個叫做Paintlets的東西！ 這是一個 Paintlets.Herokuapp.com，如果您訪問 Chrome，不幸的是，您必須這樣做，因為它還沒有得到很好的支持。 你可以看到一堆不同的、隨機的藝術品隨機生成的藝術品……是的，我剛剛……這就是我一直在做的，抱歉。 長篇大論。

德魯：太棒了。 聽起來不錯。

傑里米：是的。 是的。

Drew：親愛的聽眾，如果您想從 Jeremy 那裡聽到更多信息，您可以在 Twitter 上找到他，他是 @malchata，並在他的個人網站 jeremy.codes 上找到他的寫作演示、視頻和項目，負責任的 JavaScript 現在可以從 A分開預訂。 您可以在 Responsiblejs.dev 上找到更多相關信息。 謝謝你今天加入我，傑里米，你有什麼告別的話嗎？

傑里米：繼續前進，以最好的方式為網絡構建，並嘗試將用戶牢記在心。 這就是我的口頭禪，我希望這本書能讓我堅持下去。