JS vs TS二分法博弈

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

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

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

免責(zé)聲明

本文屬于是語(yǔ)冰的直男翻譯了屬于是，略有刪改，僅供粉絲參考，英文原味版請(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í)間編寫(xiě) PHP、Python、JS、TS、Go 以及一點(diǎn)點(diǎn) Java 和 Rust 后，我學(xué)會(huì)了鑒賞這 2 種編程范式。我十分享受至死不渝地追求正確的類型，然后沉醉于它們提供的安全套，同時(shí)我完全擁抱動(dòng)態(tài)類型系統(tǒng)的自由，快速地組合東東。于我而言，這只是 2 種一龍一豬的樂(lè)趣。

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

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

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

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

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

我不是專業(yè)的前端開(kāi)發(fā)者，我構(gòu)建 UI 的策略一直是“不斷更改代碼，直到它一切順利，并且研發(fā)之旅的阻力越少越好。”盡管我尊重和熱愛(ài)靜態(tài)類型語(yǔ)言，但在開(kāi)發(fā)的早期階段，當(dāng)代碼庫(kù)可以在一周內(nèi)多次完全重寫(xiě)時(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ì)顯著減慢開(kāi)發(fā)速度，但與 UI 組件不同，API 表面是一個(gè)更加穩(wěn)定的領(lǐng)域。為它編寫(xiě)黑盒測(cè)試?yán)硭?dāng)然。

最初，這些測(cè)試旨在成為一個(gè)驗(yàn)收套件，用于端到端檢查系統(tǒng)，包括遠(yuǎn)遠(yuǎn)超出 JS API 的組件（即上游服務(wù)）。但時(shí)過(guò)境遷，它們也成為驗(yàn)證 JS 代碼更改的主要手段。我對(duì)這個(gè)項(xiàng)目的現(xiàn)狀心滿意足 —— 僅通過(guò)一組測(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)重大。在沒(méi)有類型提示的情況下，處理大量屬性或構(gòu)建 Kubernetes 對(duì)象的復(fù)雜圖頭皮發(fā)麻，并且在沒(méi)有類型檢查或測(cè)試的情況下重構(gòu)這樣的代碼庫(kù)已被證明十分容易翻車。

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

• 開(kāi)始為 UI 組件編寫(xiě)測(cè)試

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

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

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

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

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

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

最新評(píng)論