JS vs TS二分法博弈

在“JS 教”和“TS 教”的圣戰(zhàn)中，除了狂熱的虔信徒，還有像 up 主這種佛系的“無神論者”所以 JS 和 TS 互利共生或許可以成為“二極管思維”的第三個(gè)正確的選擇。

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

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

免責(zé)聲明

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

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

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

前端項(xiàng)目測(cè)試

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

• 一個(gè)是經(jīng)典的帶有 API 的“網(wǎng)站”

• 一個(gè)是非經(jīng)典的高度動(dòng)態(tài)的 Kubernetes Explorer SPA（單頁應(yīng)用程序）

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

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

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

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

Kubernetes Explorer SPA 遷移到 TS

那么，為何我還決定將另一個(gè)項(xiàng)目 Kubernetes Explorer SPA 遷移到 TS 呢？

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

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

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

• 開始為 UI 組件編寫測(cè)試

• 引入類型系統(tǒng)

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

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

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

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

以上就是JS vs TS二分法博弈對(duì)比分析的詳細(xì)內(nèi)容，更多關(guān)于JS TS二分法對(duì)比的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論