编程与软件工程neugierig.org
Google 如何使用 TypeScript
TypeScript at Google
2018 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇 2018 年的博文讨论 Google 内部采用 TypeScript 的背景与权衡：面对庞大的既有 JavaScript 代码库，为何不直接换一门新语言，以及渐进式迁移在工具链、互操作和工程组织上的现实问题。文中也涉及与 Closure 等既有工具的关系；2021 年的后续评论显示迁移后来进展顺利。
为什么经久不衰：它从一个超大规模代码库的约束出发，解释了 TypeScript 渐进式迁移为何比“换语言重写”更可行，而后续评论又印证了这条路径的长期效果。
HN 评论精选
换语言无法绕开语义模拟和生态成本，所以渐进采用 TypeScript 更务实。
最先想到的诱人选项是干脆抛弃这个被毁掉的星球，另找一个完全不用 JavaScript 的新大陆：要是多投资 GWT、Dart、WASM 或你喜欢的语言就好了！我在 Google 开始做 TypeScript（我和 Evan 一起负责这件事）时想了很久，最终说服自己：换一门语言解决不了我们面对的问题。理由是：如果前端开发不用 JavaScript，你总有所图——要么想要那门语言的语义（数组越界检查、运行时类型、方法分派等），要么想要它的生态（编辑器、IDE，尤其是库和框架）。运行时语义差得越远，需要的模拟代码就越多，代价在体积、性能、与 JS 互操作和可理解性上（总有一天你得调试编译输出）；而生态问题在于，你通常进入的是一个原本为很不同场景编写的大生态。
Nitramp查看英文原文
> The first tempting option is to just abandon this ruined planet and settle a new one that doesn't even involve JavaScript. If only we invested more in GWT (a Google project that compiles Java to JavaScript) or Dart (a Google project that compiles a new language to JavaScript) or WASM or [insert your favorite language here — Clojure? Haxe? Elm?] we wouldn't need to worry about JavaScript at all! I thought about this for quite a while when we started on TypeScript at Google (I work on this with Evan). I've convinced myself that using a different language cannot solve the problem that we're looking at. The argument goes like this: if you use a different language than JavaScript for front end development, you're (hopefully) doing it for a reason. That is, you (a) want the other languages semantics (e.g. bounds checks on array accesses, runtime types, method dispatch, you name it), or you (b) might want the programming languages ecosystem - editors, IDEs, etc; but most importantly libraries and frameworks. Most likely, you're looking for a combination of (a) and (b). The problem with (a) is that the more different the runtime semantics of your programming language are, the more emulation code you need. Emulation code is costly in code size, performance, interop with JS, and often understandability (at some point you will need to debug the output, believe me). The problem with (b) is that you typically opt into a large ecosystem that was originally written for a very different environment. This was a big issue with GWT: people would pull Java libraries, but those libraries, amazing as many are, were not written for the web or with code size in mind. This meant using a common library like Guava required a lot of engineering effort to keep code size in check. This also applies to WASM, possibly even more so. These mechanisms work together to make it very hard to hit the sweet spot between performance, developer experience, and interoperability. And ironically, the better you get at the goals you're aiming for (different semantics, different ecosystem), the farther you get away from a working solution. I don't think it's impossible to achieve a transpile-to-JS language that works really well with enough investment, but keeping in mind the other reasons Evan lists (mind share, existing code base), incrementally improving JavaScript where needed is IMHO the much more promising approach.
Dart 团队回应：Google 对 Dart 投入很大；TS 适合渐进迁移，重写则新语言可能更优。
我是 Dart 团队成员。不知道作者是否有意，但这句话可以读成 Google 对 Dart 投入不多，这不是事实。Flutter 和 Fuchsia 是使用 Dart 的高关注度项目，AdWords 也用 Dart 构建。Dart 团队规模是史上最大且在增长（具体人数不便公开）。我们有大量内部和外部 Dart 代码，增长很快。不同项目需求不同：如果你有庞大且很有价值的现有 JS 代码，渐进迁移到 TypeScript 是合理的；如果你本来就要重写大量代码、偿还技术债，那么换一门没有 JavaScript 历史包袱的新语言可能更明智。Dart 的对象模型更干净，没有 === 之类的问题；与 JS 决裂得更彻底，意味着 Dart 的类型系统可以比 TypeScript 更简单且可靠，编译器也能依赖类型做优化和压缩。
munificent查看英文原文
> If only we invested more in GWT (a Google project that compiles Java to JavaScript) or Dart (a Google project that compiles a new language to JavaScript) or WASM or [insert your favorite language here — Clojure? Haxe? Elm?] we wouldn't need to worry about JavaScript at all! I'm on the Dart team. I don't know if the author intended this, but you could read this as saying that Google isn't investing much in Dart, which isn't true. Flutter and Fuchsia are the high profile projects that use Dart. AdWords is also built in Dart. The Dart team itself is as large as its ever been and growing. (I'd give more precise numbers, but Google generally shies away from publicly stating personnel details.) We have a ton of internal and external code written in Dart, and it's growing at a nice clip. Different projects have different needs. If you have a large existing JS corpus that's providing a lot of value for you, then an incremental migration to TypeScript makes sense. If you're looking to rewrite a lot of code and pay off technical debt anyway, then moving to a new language that doesn't have all of JavaScript's baggage can be a smarter choice. Dart has a cleaner object model and fewer warts like "===", etc. Making a bigger break from JS means that Dart's type system can be simpler than TypeScript's and is sound. That in turn means the compiler can rely on types for optimization and minification.
2021 年回看：迁移成功，工具与编辑器体验大幅改善。
现在比 2018 年好多了，很大程度上要归功于他和团队的工作。TypeScript 迁移进展顺利，有很好的自动迁移工具，我现在基本只用 TS。这意味着错误信息更好，编辑器支持也更好。（披露：我在 Google 广告部门工作，仅代表个人。）
jefftk查看英文原文
Things are a lot better now than they were in 2018, in large part due to his work and his team's. The typescript migration has gone well, with good automatic migration tooling, and I mostly only use TS now. This means good error messages, and good editor support. (Disclosure: I work on ads at Google, speaking only for myself)
建议做注解 JS 到 TS 的转译或让 Closure 支持 TS，并呼吁大厂合作；同时肯定 Closure 工具包的价值。
Google 有足够资源写一个转译器，把带注解的 JS 大部分转成 TypeScript；这比到处敲随机注释舒服得多，后者让语法高亮都没那么有用。而且据我所知，还没有编辑器插件能对 Closure Compiler 注解代码做 lint。另一个选项是给 Closure Compiler 加 TypeScript 支持，但看起来不太可能，因为没有规范保证兼容。我很想看到 Facebook、Google 和微软在这个领域合作，而不是各自造三个非常相似的工具。另外，Closure 的 UI 工具包仍有很多控件堪称黄金标准，功能完整、可访问性和 i18n 都不错，值得一看。
TheAceOfHearts查看英文原文
Google has enough resources for someone to write a transpiler that can take annotated JS and convert most of it to TypeScript. It's certainly much more pleasant than having to type random comments everywhere, which kinda makes syntax highlighting way less useful. Oh, and last I checked there were no editor plugins for linting Closure Compiler annotated code. Another option would be to add TypeScript support to Closure Compiler, although it doesn't seem likely since there's no spec to guarantee compatibility. I'd love to see Facebook, Google, and Microsoft team up in this space, instead of creating 3 separate but very highly similar tools. Also, while we're talking about Closure, let's take a moment to appreciate its amazing UI toolkit [0]. I'd still consider many of their widgets to be the gold standard. It's written with desktop clients in mind and is incredibly feature-complete. I believe it also has pretty good accessibility, although I haven't personally tried that out. Oh, and don't forget the i18n as well! The closure library definitely has a lot of quirky aspects to it, but it's still quite amazing if you consider its age and how much stuff it supports. It's worth taking a few minutes to browse through their docs [1]. [0] https://google.github.io/closure-library/source/closure/goog/demos/index.html [1] https://google.github.io/closure-library/api/
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选