我最近看到了這種趨勢：越來越多的開發人員抨擊 TypeScript。人們的抱怨範圍從「太複雜」到「減緩開發」。
雖然並非所有擔憂都是沒有根據的，但2024 年對 TypeScript 的憎恨是不成立的。
讓我們來分解一下。 🔍
TypeScript 不是你的敵人，而是你的安全網
我明白了——JavaScript 是靈活的、動態的，並且可以讓你快速交付程式碼。但同樣的靈活性也導致了難以發現的錯誤，直到為時已晚。 TypeScript 的嚴格性不是為了讓你放慢速度；而是為了讓你放慢腳步。它可以讓您免於花費數小時來除錯本來可以及早發現的問題。
這是一個例子：
let id;
getUserByID(id);理論上， id可以是數字、UUID、隨機字串或結構化字串。但根據它的類型，如果您嘗試增加它或將其傳遞給期望它具有特定結構和類型的 API，則可能會收到錯誤。
而且你可以透過查看它的使用方式來判斷它是什麼類型。但你知道是什麼讓這不再是問題嗎？
let id: number;
function getUserByID(id: string) {...}
// and that's the most basic thing you could do
getUserByID(id); // boink, error!當您將 TypeScript 新增至專案時，您就新增了一層安全性。這就像繫上安全帶一樣。當然，您可以在沒有它的情況下開車，但是當一個簡單的預防措施可以使您免於撞車事故時，為什麼還要冒險呢？ 🚗💥 在軟體品質比以往任何時候都更重要的時代，TypeScript 的類型檢查是一種有意義的保障。
它並不像你想像的那麼複雜
我經常聽到的另一個抱怨是 TypeScript「太複雜」。但說實話，JavaScript 可能會很混亂。接受任何輸入的函數簽名、變形的物件以及在生產中只需一處拼寫錯誤就可以破壞的程式碼。 TypeScript 並沒有增加複雜性；而是增加了複雜性。它正在將其形式化或標準化。
這樣想：
您正在開發一項功能的前端，而其他人可能有一些工作與您重疊。您還需要合併後端 API，但這些還沒準備好。無論如何，您都被要求開始 UI 工作。
如何確保您現在編寫的程式碼與您將從 API 取得的資料一致？如果 API 確實發生變化，是否有各方都需要遵守的事實來源？
這是正確的。
透過定義類型。
透過在實作開始之前定義類型，UI 和 API 之間共享哪些資料契約就不會有任何混淆，如果確實有不同，那麼需要做的就是遵循先前定義的契約。
如果你可以學習 React、使用 Webpack 或處理 async/await，那麼你就可以學習 TypeScript。更重要的是──這是一項可以帶來回報的技能。學習曲線是值得的，因為它迫使你更批判性地思考你的程式碼。您需要考慮架構、類型和長期可維護性，而不是拼湊出一個快速修復方案。 🛠️
開發速度更快，而不是更慢
有一種說法認為 TypeScript 會減慢開發速度。但實際上，情況往往恰恰相反。透過在編譯時而不是執行時捕獲錯誤，從長遠來看，TypeScript 可以幫助您更快地前進。您不會把時間花在瀏覽器控制台上，追蹤未定義的變數或奇怪的類型強制。 🚀
TypeScript 的工具也是一流的。
自動完成、重構工具和內嵌文件等功能使開發體驗更加順暢。您不僅僅是在編寫程式碼，您是在一條光線充足、標記清晰的道路上行駛，而不是在黑暗中跌跌撞撞。 🌟
這是一個個人軼事。
在我完全接受 TypeScript 之前，我經常發現自己陷入了程式碼庫考古的雜草之中。我遇到一個函數，但不知道它應該採用什麼參數。是一條繩子嗎？一個東西？該物件需要哪些參數？哪些是可選的？看起來可選的東西實際上是呼叫堆疊中某個地方所需要的嗎？
因為開發人員並不完美，糟糕的變數名稱、不一致的命名約定以及編碼偏好始終會成為障礙…
所以，我會跳舞：滾動回到函數的聲明，挖掘實現，嘗試拼湊出應該放在哪裡的東西。如果自動完成功能可以拯救我呢？忘了它。這是沒用的。程式碼編輯器和我一樣一無所知。 😅
當然，您可能會說 JSDoc 註釋可能會有所幫助。但是，如果您要花費所有精力來手動記錄類型和函數簽名，那麼您為什麼要自己這樣做呢？您基本上正在執行 TypeScript 的工作，但沒有任何實際好處。 TypeScript 消除了所有猜測，讓您充滿信心、快速地進行程式設計。
TypeScript 是未來（也是現在）
TypeScript 現已推出第五版。在GitHub上基本上有100k star 。它在 NPM 上每週的下載量超過 5500 萬次。越來越多的重大專案和公司正在採用它。這是有原因的：TypeScript 為程式碼庫帶來了穩定性、可擴展性和信心。這不僅僅是關於今天的專案，而是關於建立一些可以成長和發展而不會在自身重量下崩潰的東西。這是關於不必一直單獨編寫文件和測試（當然，它並不能完全取代它們）。
那麼，讓我們消除噪音。 TypeScript 在 2024 年受到的仇恨很大程度上是錯誤的。當然，它並不完美——沒有任何工具是完美的。但好處遠大於缺點。是時候停止將 TypeScript 視為障礙，而開始將其視為必不可少的工具了。
擁抱它，學習它，你會發現自己可以更快地編寫更好的程式碼。 💪
TypeScript 並不完美，但不要讓完美成為優秀的敵人！
當然，TypeScript 並非沒有缺陷。一個合理的抱怨是在一個沒有考慮到它的專案中設定它的開銷。將遺留程式碼庫轉換為 TypeScript 可能是一個耗時的過程，對於時間緊迫的團隊來說並不總是可行。 ⏳
此外，有時 TypeScript 嚴格的類型系統可能會讓人感覺它在與你作對，而不是幫助你，特別是當你處理複雜類型或尚未正確類型化的第三方函式庫時。
TypeScript 的好壞取決於開發人員對其的配置。
我參與過多個 TS 專案，其中一些專案的配置相對寬鬆，允許人們使用any類型或避免嚴格或null檢查。您將非類型化或鬆散類型化的程式碼混合到類型化的程式碼庫中，情況最終可能會變得非常糟糕。
我們該去哪裡？
也就是說，這些都是為了長期利益而付出的短期痛苦。是的，一開始它可能會減慢您的速度，但是您獲得的穩定性和可維護性足以彌補它。
這些問題在幾年前曾經更加嚴重，但現在可以說已經好多了。
我認為，花點功夫去學TS。 TS 使您能夠將其部分引入現有程式碼庫 - 嘗試一下。或者也許建立利用 TypeScript 的較小的寵物專案。
另外，根據最近的StackOverflow 調查，TS 開發人員比 JS 開發人員賺的錢多一些。
說到更好的程式碼......
如果您對 TypeScript 如何升級現實世界的專案感到好奇：
https://github.com/middlewarehq/middleware ⚡️ 查看中介軟體儲存庫 ⚡️
這是 TypeScript 實際應用的一個很好的例子，誰知道呢——你可能會為自己的專案找到一些想法！ 🚀
更好的是，告訴我們我們的程式碼為什麼不是最好的！
如果您有一些可靠的建議，我將修改帖子以將其作為示例！
原文出處：https://dev.to/middleware/why-hating-typescript-in-2024-doesnt-make-sense-44e
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式