我曾經是將 TypeScript 推向每個專案的開發人員。後端？ TypeScript。前端？ TypeScript。一個五分鐘的腳本來自動重命名檔案？是的，甚至如此。這似乎是正確的舉措——畢竟，靜態類型讓一切變得更好，對吧？
嗯，並非總是如此。
多年來，我一直強迫自己將 TypeScript 引入每個專案，現在我終於承認了一件事：對於小型專案來說，TypeScript 帶來的麻煩多於幫助。如果我正在啟動一個快速 MVP、個人專案或一個簡單的 API，我不再預設使用 TypeScript。原因如下。
1. 設定開銷不值得
讓我們面對現實吧—TypeScript 需要設定。
-
配置
tsconfig.json -
確保依賴項與 TypeScript 相容
-
安裝和設定類型定義（
@types/whatever） -
調整建置流程
是的，我知道 Vite、Next.js 或 Nuxt 等現代框架透過零配置模板使設定更容易。但是，當您從頭開始或不使用完整框架時，該配置仍然存在 - 對於快速破解或腳本，我寧願避免這種摩擦。
對於大型專案來說，這種設定很有價值。但是對於一些小事（例如快速 API 或週末副專案） ，為什麼我要花 20 分鐘處理配置而不是實際編寫程式碼呢？
一個簡單的 JavaScript 檔案就可以完成：
// index.js
console.log("Hello, world!");有了 TypeScript，即使是這麼基礎的事情也需要額外的步驟：
const message: string = "Hello, world!";
console.log(message);讓我們解決這個問題：不，您不需要在這裡明確註解string - TypeScript 可以很好地推斷類型。
這個例子對我來說有一點象徵意義。它代表了當涉及 TypeScript 時，即使是最簡單的腳本也會開始顯得更正式和冗長。在一個我只想列印一則訊息或點擊 API 的快速專案中，那層額外的層常常感覺像是摩擦而不是幫助。
這是在設定建置過程之前。
2. TypeScript 減慢了實驗速度
JavaScript 的最大優點之一是它的靈活性。想要提出一個概念驗證嗎？沒問題。使用 TypeScript 後，這種彈性就消失了。
假設我正在嘗試一個新的 API。在 JavaScript 中，我只需獲取一些資料並繼續：
fetch("https://api.example.com/data")
.then(res => res.json())
.then(data => console.log(data))
.catch(err => console.error(err));在 TypeScript 中？現在我需要定義類型：
interface ApiResponse {
id: number;
name: string;
email: string;
}
fetch("https://api.example.com/data")
.then(res => res.json())
.then((data: ApiResponse) => console.log(data))
.catch(err => console.error(err));當然，TypeScript 允許您使用any或逐步引入類型。但這首先違背了使用 TS 的目的，對嗎？我的觀點是——當我處於實驗模式時，我根本不想考慮類型。我希望得到快速的回饋並且不產生任何摩擦。
當然，它更安全——但如果我只是玩玩而已，為什麼我在知道這個 API 是否有用之前就要編寫額外的程式碼？
3. TypeScript 的優勢在小型專案中就沒那麼有用
我明白了——TypeScript 有助於防止錯誤。但在小專案中，這真的很重要嗎？
大多數時候，TypeScript 在小專案中預防的「錯誤」都是我會立即發現的。
不好的例子：
const age = "30";
console.log(age * 2); // NaN好的，TypeScript 會捕捉它。但這是讓我徹夜難眠的病毒嗎？不。如果我的整個應用程式有 500 行程式碼，我就不需要編譯器來保護我——我只需閱讀程式碼即可。
4. 額外的建造步驟感覺不必要
使用 JavaScript，我可以立即執行我的腳本：
node script.js使用 TypeScript，我必須先編譯它：
tsc script.ts && node script.js為了一個大型專案？沒問題。但是，如果我正在編寫一個快速實用程式腳本，這個額外的步驟就會扼殺動力。
是的，我知道您可以使用ts-node來避免手動編譯，但它仍然會引入不必要的複雜性。
5. 並非所有依賴項都能與 TypeScript 相容
您是否曾經安裝第三方套件並立即遇到 TypeScript 錯誤？
Property 'xyz' does not exist on type 'SomeModule'.然後您檢查該套件的 GitHub 儲存庫，發現它不支援 TypeScript 。現在你有三個選擇：
-
尋找 DefinitelyTyped 套件（
@types/xyz） （如果存在）。 -
編寫您自己的類型定義（呃）。
-
使用
any並假裝 TypeScript 不存在。
如果我正在做一個大專案，我會花時間去弄清楚這一點。但對於小型應用程式來說，這只是另一個令人頭痛的問題。
當我仍然使用 TypeScript 時
我並不是說 TypeScript 不好——我仍然會在合適的專案中使用它。
✅大型應用程式（尤其是有多名開發人員的應用程式）。
✅考慮長期維護的專案。
✅嚴重依賴模組之間嚴格契約的程式碼庫。
但對於：
❌副專案
❌快速腳本
❌ MVP 和原型
我堅持使用 JavaScript。當你不需要與編譯器鬥爭時，它會更快、更簡單、更有趣。
TypeScript 是一種工具，而不是宗教
有些開發人員將 TypeScript 視為2025 年編寫 JavaScript 的唯一方法。但事實並非如此。 TypeScript 在有意義的地方使用時非常棒 —— 但是強制將它應用到每個專案中嗎？這只會造成不必要的摩擦。
如果你喜歡 TypeScript，那太好了——在對你有利的地方使用它。但如果你正在做一些小事，並且覺得 TypeScript 帶來的麻煩多於它的價值……或許確實如此。
您的看法是什麼？你還在用 TypeScript 做所有事情嗎，還是已經開始選擇你的戰鬥了？讓我們在評論中聊天吧！
原文出處：https://dev.to/holasoymalva/stop-using-typescript-for-small-projects-47hl
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式