JS vs TS：二分法博弈
大家好，這里是大家的林語冰。“TS 涼涼”的前端都市傳說今年在前端娛樂圈收割了一大波流量和熱度，一時甚至有些許出圈。雖然但是，在“JS 教”和“TS 教”的圣戰中，除了狂熱的虔信徒，還有像 up 主這種佛系的“無神論者”（其實老粉都知道，語冰乃地球貓貓教的虔信徒），所以 JS 和 TS 互利共生或許可以成為“二極管思維”的第三個正確的選擇。
本期《前端翻譯計劃》共享的是一種偏向實用主義的前端技術立場，惟愿 JS 和 TS 從此握爪言和，別再搞窩里斗，愿前端生態從此世界核平，贊美女神~
DHH 最近發布的關于 Turbo 8 轉身出軌 JS，和 TS “和平分手”的博客，剎那間前端人集體破防，TS 愛好者和“類型體操受害者”開始對線，俺也不例外。夭壽啦，我甚至不知道 Turbo 8 是什么鬼物，但私以為本人也可以自由言論。就在幾周前，在下將兩個最大的項目之一遷移到了 TS，同時保留了另一個使用 JS 的項目，目前這正是本人的最佳選擇，沒有之一，成年人全都要，喵星人才選擇困難。
圖片
免責聲明
本文屬于是語冰的直男翻譯了屬于是，略有刪改，僅供粉絲參考，英文原味版請傳送 JavaScript or TypeScript? How To Benefit From the Dichotomy[1]。
在解釋本人的動機之前，讓我先免責聲明 —— 我既喜歡靜態類型的嚴謹性，也喜歡動態類型的易用性。在花了多年時間編寫 PHP、Python、JS、TS、Go 以及一點點 Java 和 Rust 后，我學會了鑒賞這 2 種編程范式。我十分享受至死不渝地追求正確的類型，然后沉醉于它們提供的安全套，同時我完全擁抱動態類型系統的自由，快速地組合東東。于我而言，這只是 2 種一龍一豬的樂趣。
雖然但是，我更享受實用主義。其主要目標旨在項目開發的各個階段快速迭代，如果說這意味著技術的改變，那就且當做是這樣吧。
現在，回到我最近的經歷。自去年 12 月以來，我一直致力于 2 個巨型前端項目：
- 一個是經典的帶有 API 的“網站”
- 一個是非經典的高度動態的 Kubernetes Explorer SPA（單頁應用程序）
我不是專業的前端開發者，我構建 UI 的策略一直是“不斷更改代碼，直到它一切順利，并且研發之旅的阻力越少越好。”盡管我尊重和熱愛靜態類型語言，但在開發的早期階段，當代碼庫可以在一周內多次完全重寫時，類型可能是障礙之一。這就是我使用 JS 啟動這兩個項目的原因。
9 個月轉瞬即逝，我仍然對在“網站”中使用 JS 心滿意足。該項目是 UI（Vue）和 API（Nuxt）組件的結晶。 UI 組件豐富但簡單 —— 大多數時候，當我發現 UI 回歸時，這是由于 CSS 或 HTML 的更改，而不是因為我搞亂了代碼。
API 并不那么簡單 —— 傳統的 BFF（backend for frontend）邏輯（比如授權/身份驗證、數據轉換等）與自定義課程管理和車隊編排邏輯交織在一起，并分布在數十個 API 處理程序中。這種架構（或缺乏這種架構）可能會顯著減慢開發速度，但與 UI 組件不同，API 表面是一個更加穩定的領域。為它編寫黑盒測試理所當然。
最初，這些測試旨在成為一個驗收套件，用于端到端檢查系統，包括遠遠超出 JS API 的組件（即上游服務）。但時過境遷，它們也成為驗證 JS 代碼更改的主要手段。我對這個項目的現狀心滿意足 —— 僅通過一組測試就實現了一大坨目標，并且不需要繁重的 TS 機械，我還能奢求什么呢？
圖片
那么，為何我還決定將另一個項目 Kubernetes Explorer SPA 遷移到 TS 呢？
答案在于該項目提出了不同的約束和需求。與 iximiuz Labs 網站的主要復雜性聚焦于 API 層不同，Kubernetes Explorer 最頭大的部分是它的 UI 組件。
Explorer 的主要邏輯駐留在瀏覽器運行的代碼中，這事關重大。在沒有類型提示的情況下，處理大量屬性或構建 Kubernetes 對象的復雜圖頭皮發麻，并且在沒有類型檢查或測試的情況下重構這樣的代碼庫已被證明十分容易翻車。
圖片
在對資源管理器的 UI 進行另一次大型更改之后（其中回歸搜索花費的時間比實際重寫的時間更長），我決定是時候優化 DX（開發者體驗）了。本質上，我有 2 個選擇：
- 開始為 UI 組件編寫測試
- 引入類型系統
測試自然棒棒噠，而且它們與我的其他項目無縫銜接，但根據以往的經驗，對于快速變化的領域，測試弊大于利。維護測試套件可能會成為一種真正的負擔，并且開發者往往會越來越依賴經過高度測試的組件，當它們不再適合 UI 時，就很難舍棄它們。
與此同時，到目前為止，我在項目中遇到的大多數回歸都是，由于缺少屬性或一種形狀的對象，意外傳遞給需要不同形狀對象的函數導致的 —— 編譯器的輔助通常可以避免此問題。因此，我決定將項目遷移到 TS，并暫時將測試數量保持在最低限度。2 周后重寫了 3 次，我對自己的選擇心滿意足。
我將來會向 Kubernetes Explorer 添加更多 UI 測試嗎？大概也許可能吧。我會將網站遷移到 TS 嗎？大概也許可能吧。有一天我會恢復使用此 App 的 JS 嗎？答案是肯定的，前提是我發現它可以輔助我快速迭代。
當然，您的里程可能會有所不同。項目的性質差異很大，且沒有一種通用的語言或解決方案。我的個人建議是，保持務實，選擇最佳工具，避免教條主義的條條框框。
