Aloha, Ohayo!
发布于

从TypeScript看出去：AI时代的编程语言趋势

作者

@Author: Garfield Zhu

引：10年前每周刷技术论坛的时候，TIOBE 编程语言排行榜上各个语言的起起落落总是一个有趣的谈资，每个月都得看一眼。那排的是影响力和流行度，或者说就是搜索量。霸榜的常年都是 Java, C 和后来的 Python，既是最好找工作的语言，也是被“黑”的最多的语言，毕竟黑流量也是流量。那用的人少的语言自然差评就少，反而出好语言。 而后来嘛，Github Octoverse 给出的报告更贴近大家实际在写什么在提交什么。那去年2025的报告就反映了一个很有意思的趋势了，TypeScript 碾压式地登顶，成为最多被使用的语言，甚至大幅领先 LLM 前最好的AI语言 Python。这就很值得玩味了。

是的，Github上2025年使用量第一的语言是 TypeScript，不是最多人的Java，JavaScript，也不是机器学习也好 Transformer 也好属于AI的王者Python，而是大前端时代曾经风风火火却似乎从未真正超越JavaScript本身的TypeScript。

其实我多少是挺吃惊的，虽然对我来说可能是写的最多的语言之一了（可能是因为React该死的工作量和复杂的组件类型），而且这里也能找到我曾写过的TypeScript的博客，做做类型体操啊实践函数式编程啥的。我个人也将其和VS Code并列视为新时代的微软最出色最提高好感度的成就。

但我也有点相信他不会成为大火的语言，至少跟第一不沾边，毕竟在三年多前的社区讨论里已经退潮了。我是在 DHH 大佬——也就是Ruby on Rails的作者——在2023年的博客《Turbo 8 is dropping TypeScript》里开始看到TS带来的复杂和限制对开发者带来的心智负担。作为Ruby界的真神，DHH对解释型语言的理解完全无需质疑，他对TS的批评和弃用，以及彼时社区里的"Farewell, TypeScript"浪潮，都是有理有据的。如果它最后成为了any-script，那它只是体验更糟有着额外编译时间的Javascript了。 诸如Js Doc之类的更轻量更贴近原生Js，更少tradeoff的方式也许会终结TypeScript吧...吗？

显然三年后，事情完全抄着另一方向发展了。TypeScript 俨然就是AI时代的王者。而DHH的Turbo项目当时移除TypeScript的PR下面的讨论，今天还是很值得回过头来再看一遍双方各自的争论的。倒是不论对错，只看看论据在今天的意义。

DHH 的 TypeScript 转 JavaScript 插图

为什么是TypeScript

如今我甚至不太能见到曾经很常见的Ts + Js混合项目了，AI 在处理类型系统时太强了。类型推断是一种极具确定性的推理过程，而反过来上下文中确定的输入输出类型，也帮助AI在实现时有了明确的约束和较少的歧义。

相反的，Js Doc能带来相似的类型补全和IDE warning是给人看，Agent感知不到它的存在，它提供给agent的语义跟写成自然语言的注释并无二致。反而可能是额外的上下文拖累，作为注释也容易在上下文压缩中被丢弃。

/**
 * @param {User} user
 */
function save(user) {}

AI 带来了什么

  • 毋庸置疑，AI 对类型系统的理解和推理能力，让静态类型语言的优势在开发过程中得以充分发挥。在 vibe coding 中，推理成本也会明显低于使用弱类型语言。
  • 编译器就是 AI 高效、低开销的验证工具。编译期的类型错误可以提前暴露许多问题，而不必等到运行时才发现。弱类型语言在 AI 辅助下当然也能生成正确代码，但类型不明确仍容易引入潜在的运行时错误；这类问题往往要等到调用 Playwright 跑自动化测试时才会暴露，发现、修复、重跑的开销都很大。
  • Agent 给静态类型语言带来了一个快速而便宜的闭环：“生成 → 编译（类型检查）→ 报错 → 修复 → 再编译 → 通过”。多轮修复的时间成本取决于编译速度；而且类型错误信息通常精准明确，不需要大量上下文就能理解，可以显著降低整体的时间和 token 开销。

Agent 需要什么

很长一段时间里，AI 几乎等同于 Python。从 PyTorch、TensorFlow、NumPy、Pandas 到 CUDA，Python 几乎处于统治地位。进入 ChatGPT 开启的 LLM 时代后，Python 仍然是核心。

但是，Agent 的出现也在 LLM 之外带来了巨大的软件生态需求：

  • 从 LLM API、tool calling、MCP、Agent Skills 到 Harness，对 LLM 的调用与管理不断迭代；除了提供更强的功能，也对软件生态提出了更高要求。
  • 从 Cursor、Claude Code 到 Codex，多端 AI 编程助手层出不穷，也推动了更高效、更智能的软件生态。CLI、TUI、App、plugin 等形态都找到了自己的受众。OpenCode、PI、DeepSeek Harness 等开源 Agent 也带动了整个生态上下游的发展。
  • 这些现代 AI App 既需要在服务端管理 LLM、Tools、MCP 和 DB，也需要提供面向网页、客户端和 VS Code 插件的 UI。恰好，从 Web、Electron/Tauri 到 Node.js，都是 TypeScript 的舒适区。
  • TypeScript + Zod 提供了 Schema。LLM 的输出规范、API 的负载格式、tool 和 MCP 的参数及输出格式等，都需要明确的 Schema。通过 TS 生成 Schema 并进行验证，项目中的编译期类型、运行时 JSON Schema 和 LLM 输出格式都可以共享一套统一的合约规范，价值不言而喻。
  • 此外，一个 npm 包分发给前后端共同使用，也轻松愉快。

因此，TypeScript 在现代 AI 驱动的多端应用开发中，成了天然的选择。

恰逢一个更快的TypeScript

作为2.x时代入坑的选手，我是追着很多迭代中的Ts语法更新的，尤其是问号套餐(可选链?.，空值合并??)。但今天其实我的项目里多都停在了5.x，因为它很成熟了，无论是类型系统，还是领先ES标准的新特性。 但不得不说，基于golang实现的TypeScript 7真的很快，它太快了所以真的很重要。即便说不同于大型C++, Rust项目可以到几十分钟到小时级的完整编译时间，但把tsc的编译时间从60s降到10s真的是重大改善，尤其在Loop Engineering下的Agent，可以更快的在修改->验证中->再修改中迭代前进，也更容易发现类型错误可能造成的影响。 一个明确调用成本更低的tsc，也会大幅提高agent本身调用这个工具的意愿，反过来影响Harness的设计。

目前唯一让我没有动力去把旧项目们升级到ts7的原因，是它(@7.0.2)只发布了编译器tsc却还没有API。项目里依赖了诸如typescript-eslint之类需要通过API访问编译器的工具无法使用ts7，而仍然需要使用ts6.0的API。 所以目前你们的package.json里还需要这样来使用7.0的tsc，且工具仍使用6.0：

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}

所以吧，TypeScript 7.1 可搞快点吧微软！

曾经我们在写什么

在过去的编程语言迭代中，加入更多现代语法糖，往往是更新日志里最靠前、最吸引眼球的部分。老古董 Java 往接口里塞私有方法，塞进 var、record、三引号文本块等特性，足以让 Java 8 程序员眼前一黑又一黑。 所以，善用先进语法偷懒、提高代码的信息密度，是提升人类程序员效率的重要手段。

比起让老语言挣扎着改进，能让人写得舒服的，肯定是高效而易用的语言；JS 和 Python 无疑是其中的翘楚。多数时候，大家都愿意牺牲一些语言性能，换取更高的开发效率。

所以 AI 擅长些什么，适合写什么

AI 擅长处理大量结构化和非结构化数据，也擅长推理复杂的逻辑关系。这使静态类型语言的编译器成为 AI 的强力工具。

同理，Rust 是一门非常有意思的语言。它在编译期进行生命周期和所有权检查，在安全代码中保障内存安全与数据竞争安全，但要通过编译，相比其他语言就困难得多。 这种编译难度给人类程序员带来相当大的心智负担；然而，对 AI 来说，推理所有权和生命周期与类型推理类似，反而轻而易举。借助充足的编译器错误信息（例如 value borrowed here after move），AI 可以快速定位并修复问题。因此，“修改 → 编译验证 → 再修改”的飞轮在 Rust 中同样可以高效运转，同时带来强大的内存安全保障。 优秀的数据竞争安全保障，也能帮助 AI 在编译期尽早发现潜在的数据竞争风险，减轻端到端并发测试的压力。

而且，作为一门更现代的语言，Rust 的工具链系统更加自洽、完善。标准化工具链，而非第三方库，保证了所有 Rust 项目的统一性：

cargo check
cargo fmt
cargo clippy
cargo test
cargo doc

Agent 因此减少了调查和学习工具链的上下文开销，不必理解和猜测该用 pip 还是 uv、webpack 还是 Vite，直接按照标准化工具链命令操作即可。

由此导致的问题

毫无疑问，由于 Agent 不可避免地在开发中占据越来越重要的地位，TypeScript、Rust、Python这类更适合 AI 的语言，以及 React 这类前端框架，新项目几乎都倾向于围绕这些技术栈展开。 多数时候这些技术栈几乎并不比其他的更好、更适配项目的实际需求，它们通常只是更通用、更容易被 AI 理解和维护。它们可能在性能上、灵活性甚至现代化上有所妥协，在 Agent 带来的成本、效率和维护性的优势下通常会被更优的选择。

而一些老项目也正迅速向这些技术迁移，以便更好地 Agent 协作开发并更容易标准化 Agent 产出的代码质量。当然，Agent 本身也降低了迁移技术栈这个巨大工程的成本和周期，由此产生的便利与效率让这类决策更容易被项目维护者们接受。例如著名的 bun 迅速完成从 Zig 到 Rust 的百万行迁移。

更新: SolidJS 的作者前几天发了一篇 Nobody Argued For Your Stack，由于 Cursor 从 SolidJS 迁移到了 React，产生了很多讨论和思考。SolidJS 当然更新更快更灵活，比起带着沉重的vDom，不同重复渲染的 React要优雅而高效。 如今迁移的成本太低了，当项目刚开始的时候选择最轻量最新颖的技术，做大了或者遇到问题了那就转向多数人多数项目的选择无疑最为稳妥，也更可持续。那么，所有大象们都走上这条路，代价会是什么呢？(笑

可以预见的是，曾经百花齐放的编程语言，开发框架，等等可能都将逐渐趋同化。更适合大模型的，源码语料更丰富的技术将会赢家通吃，成为多数项目的选择。 不知道会不会有专门直接为 AI 设计和优化的编程语言或框架出现，来取代当前主流的 AI 偏好技术，毕竟它们本来仍然是为程序员创造的，只是某些特征或是流行度在 AI 浪潮下吃到了红利。我个人猜测是会的，唯一的挑战是这样的新技术会怎么流行起来，毕竟足够流行了才能有足够的语料成为 AI 的偏好。

时也，命也

Turbo 依然是个好项目，它助力超快的SPA开发，一个醒目的100% JavaScript语言条，和一堆被关闭的"Add TypeScript back"之类的PR。

2023年才过去3年，那时ChatGPT才问世几个月，那时大家还在讨论生成式AI元年，那时还没有 Agent 和 vibe coding 也没人把代码交给AI，那时前端世界仍鲜花着锦、烈火烹油。

而如今，我已经很长时间没看到有人争论 React 和 Vue 的问题了，所以，前端大抵真的是已经死了罢。。。

在 Twitter 讨论 • 在 GitHub 查看