大家好，這里是大家的林語冰?！癟S 涼涼”的前端都市傳說今年在前端娛樂圈收割了一大波流量和熱度，一時甚至有些許出圈。雖然但是，在“JS 教”和“TS 教”的圣戰(zhàn)中，除了狂熱的虔信徒，還有像 up 主這種佛系的“無神論者”（其實老粉都知道，語冰乃地球貓貓教的虔信徒），所以 JS 和 TS 互利共生或許可以成為“二極管思維”的第三個正確的選擇。

本期《前端翻譯計劃》共享的是一種偏向?qū)嵱弥髁x的前端技術(shù)立場，惟愿 JS 和 TS 從此握爪言和，別再搞窩里斗，愿前端生態(tài)從此世界核平，贊美女神~

DHH 最近發(fā)布的關(guān)于 Turbo 8 轉(zhuǎn)身出軌 JS，和 TS “和平分手”的博客，剎那間前端人集體破防，TS 愛好者和“類型體操受害者”開始對線，俺也不例外。夭壽啦，我甚至不知道 Turbo 8 是什么鬼物，但私以為本人也可以自由言論。就在幾周前，在下將兩個最大的項目之一遷移到了 TS，同時保留了另一個使用 JS 的項目，目前這正是本人的最佳選擇，沒有之一，成年人全都要，喵星人才選擇困難。

圖片

免責(zé)聲明

本文屬于是語冰的直男翻譯了屬于是，略有刪改，僅供粉絲參考，英文原味版請傳送 JavaScript or TypeScript? How To Benefit From the Dichotomy[1]。

在解釋本人的動機之前，讓我先免責(zé)聲明 —— 我既喜歡靜態(tài)類型的嚴(yán)謹(jǐn)性，也喜歡動態(tài)類型的易用性。在花了多年時間編寫 PHP、Python、JS、TS、Go 以及一點點 Java 和 Rust 后，我學(xué)會了鑒賞這 2 種編程范式。我十分享受至死不渝地追求正確的類型，然后沉醉于它們提供的安全套，同時我完全擁抱動態(tài)類型系統(tǒng)的自由，快速地組合東東。于我而言，這只是 2 種一龍一豬的樂趣。

雖然但是，我更享受實用主義。其主要目標(biāo)旨在項目開發(fā)的各個階段快速迭代，如果說這意味著技術(shù)的改變，那就且當(dāng)做是這樣吧。

現(xiàn)在，回到我最近的經(jīng)歷。自去年 12 月以來，我一直致力于 2 個巨型前端項目：

• 一個是經(jīng)典的帶有 API 的“網(wǎng)站”
• 一個是非經(jīng)典的高度動態(tài)的 Kubernetes Explorer SPA（單頁應(yīng)用程序）

我不是專業(yè)的前端開發(fā)者，我構(gòu)建 UI 的策略一直是“不斷更改代碼，直到它一切順利，并且研發(fā)之旅的阻力越少越好。”盡管我尊重和熱愛靜態(tài)類型語言，但在開發(fā)的早期階段，當(dāng)代碼庫可以在一周內(nèi)多次完全重寫時，類型可能是障礙之一。這就是我使用 JS 啟動這兩個項目的原因。

9 個月轉(zhuǎn)瞬即逝，我仍然對在“網(wǎng)站”中使用 JS 心滿意足。該項目是 UI（Vue）和 API（Nuxt）組件的結(jié)晶。 UI 組件豐富但簡單 —— 大多數(shù)時候，當(dāng)我發(fā)現(xiàn) UI 回歸時，這是由于 CSS 或 HTML 的更改，而不是因為我搞亂了代碼。

API 并不那么簡單 —— 傳統(tǒng)的 BFF（backend for frontend）邏輯（比如授權(quán)/身份驗證、數(shù)據(jù)轉(zhuǎn)換等）與自定義課程管理和車隊編排邏輯交織在一起，并分布在數(shù)十個 API 處理程序中。這種架構(gòu)（或缺乏這種架構(gòu)）可能會顯著減慢開發(fā)速度，但與 UI 組件不同，API 表面是一個更加穩(wěn)定的領(lǐng)域。為它編寫黑盒測試?yán)硭?dāng)然。

最初，這些測試旨在成為一個驗收套件，用于端到端檢查系統(tǒng)，包括遠遠超出 JS API 的組件（即上游服務(wù)）。但時過境遷，它們也成為驗證 JS 代碼更改的主要手段。我對這個項目的現(xiàn)狀心滿意足 —— 僅通過一組測試就實現(xiàn)了一大坨目標(biāo)，并且不需要繁重的 TS 機械，我還能奢求什么呢？

圖片

那么，為何我還決定將另一個項目 Kubernetes Explorer SPA 遷移到 TS 呢？

答案在于該項目提出了不同的約束和需求。與 iximiuz Labs 網(wǎng)站的主要復(fù)雜性聚焦于 API 層不同，Kubernetes Explorer 最頭大的部分是它的 UI 組件。

Explorer 的主要邏輯駐留在瀏覽器運行的代碼中，這事關(guān)重大。在沒有類型提示的情況下，處理大量屬性或構(gòu)建 Kubernetes 對象的復(fù)雜圖頭皮發(fā)麻，并且在沒有類型檢查或測試的情況下重構(gòu)這樣的代碼庫已被證明十分容易翻車。

圖片

在對資源管理器的 UI 進行另一次大型更改之后（其中回歸搜索花費的時間比實際重寫的時間更長），我決定是時候優(yōu)化 DX（開發(fā)者體驗）了。本質(zhì)上，我有 2 個選擇：

1. 開始為 UI 組件編寫測試
2. 引入類型系統(tǒng)

測試自然棒棒噠，而且它們與我的其他項目無縫銜接，但根據(jù)以往的經(jīng)驗，對于快速變化的領(lǐng)域，測試弊大于利。維護測試套件可能會成為一種真正的負擔(dān)，并且開發(fā)者往往會越來越依賴經(jīng)過高度測試的組件，當(dāng)它們不再適合 UI 時，就很難舍棄它們。

與此同時，到目前為止，我在項目中遇到的大多數(shù)回歸都是，由于缺少屬性或一種形狀的對象，意外傳遞給需要不同形狀對象的函數(shù)導(dǎo)致的 —— 編譯器的輔助通常可以避免此問題。因此，我決定將項目遷移到 TS，并暫時將測試數(shù)量保持在最低限度。2 周后重寫了 3 次，我對自己的選擇心滿意足。

我將來會向 Kubernetes Explorer 添加更多 UI 測試嗎？大概也許可能吧。我會將網(wǎng)站遷移到 TS 嗎？大概也許可能吧。有一天我會恢復(fù)使用此 App 的 JS 嗎？答案是肯定的，前提是我發(fā)現(xiàn)它可以輔助我快速迭代。

當(dāng)然，您的里程可能會有所不同。項目的性質(zhì)差異很大，且沒有一種通用的語言或解決方案。我的個人建議是，保持務(wù)實，選擇最佳工具，避免教條主義的條條框框。