我曾经是那种把 TypeScript 推到公司里每个项目中的前端开发者。感觉这真是个正确的操作——毕竟，静态类型让一切都变得更好了，不是吗？
嗯，并非总是如此。
多年来，我一直强迫自己在每个项目中都使用 TypeScript，现在我终于承认了一件事：对于小型项目来说，TypeScript 带来的麻烦远大于帮助。 如果我要快速构建一个 MVP、个人项目或一个简单的 API，我不再默认使用 TypeScript。原因如下。
1. 前期准备工作不值得
让我们面对现实吧——TypeScript 需要设置。
- 配置
tsconfig.json - 确保依赖项与 TypeScript 兼容
- 安装和配置类型定义（
@types/whatever） - 调整构建过程
是的，我知道像 Vite、Next.js 或 Nuxt 这样的现代框架可以通过零配置模板简化设置。但是，当你从头开始或不使用完整框架时，这些配置仍然存在——对于快速 hack 或脚本来说，我宁愿避免这种摩擦。
对于大型项目来说，这种设置确实值得。但对于一些小项目——比如一个快速 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或逐步引入类型。但这有点违背了使用 TypeScript 的初衷，对吧？我的意思是——当我处于开发模式时，我根本不想考虑类型。我想要快速的反馈，并且没有摩擦。
当然，它更安全——但如果我只是随便玩玩，为什么我在知道这个 API 是否有用之前就编写了额外的代码？
3. TypeScript 的优势在小型项目中并不那么有用
我明白 TypeScript 有助于防止 bug。但是在小项目中，这真的很重要吗？
大多数时候，TypeScript 在小项目中阻止的“错误”都是我会立即发现的。
不好的例子：
const age = "30";
console.log(age * 2); // NaN
好的，TypeScript 可以捕获这个问题。但这种 bug 会让我彻夜难眠吗？不会。如果我的整个应用程序只有 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 做所有事情吗？还是已经开始选择自己的阵营了？欢迎在评论区留言讨论！
——转载自作者：CF14年老兵