为什么停止在小型项目中使用 TypeScript？

我曾经是那种把 TypeScript 推到公司里每个项目中的前端开发者。感觉这真是个正确的操作------毕竟，静态类型让一切都变得更好了，不是吗？

嗯，并非总是如此。

多年来，我一直强迫自己在每个项目中都使用 TypeScript，现在我终于承认了一件事：对于小型项目来说，TypeScript 带来的麻烦远大于帮助。 如果我要快速构建一个 MVP、个人项目或一个简单的 API，我不再默认使用 TypeScript。原因如下。

1. 前期准备工作不值得

让我们面对现实吧------TypeScript 需要设置。

配置tsconfig.json
确保依赖项与 TypeScript 兼容
安装和配置类型定义（@types/whatever）
调整构建过程

是的，我知道像 Vite、Next.js 或 Nuxt 这样的现代框架可以通过零配置模板简化设置。但是，当你从头开始或不使用完整框架时，这些配置仍然存在------对于快速 hack 或脚本来说，我宁愿避免这种摩擦。

对于大型项目 来说，这种设置确实值得。但对于一些小项目------比如一个快速 API 或一个周末的业余项目------我为什么要花 20 分钟来处理配置，而不是真正地编写代码呢？

一个简单的 JavaScript 文件就可以工作：

js 复制代码

// index.js
console.log("Hello, world!");

有了 TypeScript，即使是这么基础的事情也需要额外的仪式：

ts 复制代码

const message: string = "Hello, world!";
console.log(message);

让我们解决这个问题：不，您不需要string在这里明确注释 - TypeScript 可以很好地推断类型。

这个例子对我来说有点象征意义。它表明，即使是最简单的脚本，在使用了 TypeScript 之后，也会变得愈发正式和冗长。在一个我只想打印一条消息或调用一个 API 的快速项目中，这层额外的代码层往往感觉像是阻力，而不是帮助。

这是在设置构建过程 之前。

2. TypeScript 会减缓开发速度

JavaScript 最大的优势之一就是它的灵活性。想要快速完成一个概念验证？没问题。有了 TypeScript，这种灵活性就消失了。

假设我正在尝试一个新的 API。在 JavaScript 中，我只需获取一些数据并继续：

js 复制代码

fetch("https://api.example.com/data")
  .then(res => res.json())
  .then(data => console.log(data))
  .catch(err => console.error(err));

在 TypeScript 中？现在我需要定义类型：

ts 复制代码

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或逐步引入类型。但这有点违背了使用 TypeScript 的初衷，对吧？我的意思是------当我处于开发模式时，我根本不想考虑类型。我想要快速的反馈，并且没有摩擦。

当然，它更安全------但如果我只是随便玩玩，为什么我在知道这个 API 是否有用之前就编写了额外的代码？

3. TypeScript 的优势在小型项目中并不那么有用

我明白 TypeScript 有助于防止 bug。但是在小项目中，这真的很重要吗？

大多数时候，TypeScript 在小项目中阻止的"错误"都是我会立即发现的。

不好的例子：

js 复制代码

const age = "30";  
console.log(age * 2); // NaN

好的，TypeScript 可以捕获这个问题。但这种 bug 会让我彻夜难眠吗？不会。如果我的整个应用程序只有 500 行代码，我不需要编译器来保护我------我可以直接阅读代码。

4. 额外的构建步骤感觉没有必要

使用 JavaScript，我可以立即运行我的脚本：

js 复制代码

node script.js

使用 TypeScript，我必须先编译它：

js 复制代码

tsc script.ts && node script.js

对于大型项目来说？没问题。但如果我写的是一个快速实用的脚本，这个额外的步骤会扼杀我的动力。

是的，我知道可以使用它ts-node来避免手动编译，但它仍然会带来不必要的复杂性。

5. 并非所有依赖项都能与 TypeScript 兼容

是否曾经安装第三方包并立即遇到 TypeScript 错误？

bash 复制代码

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 做所有事情吗？还是已经开始选择自己的阵营了？欢迎在评论区留言讨论！