工程师亲述在 Google 从事 TypeScript 工作的独家体会！

2018年9月11日 362点热度 0人点赞 0条评论

【CSDN编者按】多年来，Google为了开发大型JavaScript应用程序而构建了大量基础架构。

今天，就来听听在TypeScript上工作了两年多的Google软件工程师Evan Martin，对此有什么心得体会吧！

我已经在TypeScript上工作了两年多了，所以我想写一两篇文章来回顾这两年的工作。首先，我应该写一个标准的免责声明：我只是一家公司的一个普通的工程师，公司拥有数万名工程师，肯定会有人对我在这里表达的观点持有不同的意见。

谷歌很早就开始做Web应用程序

Google很早就开始做Web应用程序了。我简直无法相信Gmail发布已经14年了。在当时使用JavaScript是非常疯狂的做法。Gmail的工程师不得不担心IE糟糕的垃圾回收算法，他们需要手动将字符串文字从for循环中提取出来，以避免GC（Garbage collection垃圾回收机制）停止工作。

最近我发现了一个那个时代的设计文档，他们当时在考虑做我们现在称为JavaScript“压缩”的东西，但一些备选工具只能在Windows上使用。在今天看来，这些都难以想象。

这些年，Google为开发大型JavaScript应用程序，构建了大量基础架构。例如，有一个模块系统可以让源文件表述它们的相互依赖性。有一个捆绑程序可以组合并压缩源文件，生成可以兼容浏览器的产品。

另一个程序可以通过可动态加载的入口点来分析应用的依赖关系图，并分解出公共的块供其他块使用。服务器端的渲染很常见。对于如今的Web开发人员来说，所有这些概念载熟悉不过了，但Google的技术栈很早就有了，而且一直在发展，因此在概念上类似，但具体方面完全不同，Google拥有不同的流程、工具，甚至不同的概念名称。

还有个例子可以说明并行发展：Google、Facebook和Microsoft各自构建了类似但不兼容的编译器，这些编译器向JavaScript添加了静态检查。

Google的编译器常被称为Closure。（请不要与Clojure语言混淆；为了避免混淆需要说明一下：ClojureScript使用的是Closure编译器。）

Google的JavaScript堆栈非常棒。有了它的帮助，Google才能编写并维护可以改变互联网的web应用程序。（还记得Google地图发布时，多么令人震惊吗？如今制作一个可以拖拽的地图小部件似乎非常简单。）

Google地图的一些技术甚至超越了当今最好的技术。例如，Closure编译器可能仍然是最复杂的JavaScript优化程序，它能够执行很多操作，例如利用类型信息优化代码，跨越热加载的块的边界进行函数内联，以及在符号层次删除未使用的代码等。

Google的JavaScript技术栈也存在一些问题。linter的渐进式发展表明了Closure只不过是个拥有静态类型的JavaScript，其中新功能是通过注释引入的。

Closure的语句难以捉摸，速度很慢，有很多Bug，而且如果你不会正确地使用的话，那么它往往会破坏你的代码。尽管它是开源的，但也许是正因为这些原因，除了熟悉它的Google员工之外，行业中并没有广泛使用到它。

JavaScript在Google内部的反响并不好，我认为部分原因在于我们对工具很挑剔，大家既嫌静态语言过于繁琐，又嫌动态语言不可捉摸。

JavaScript出乎意料地流行了起来

与此同时，在Google之外，JavaScript也在不断发展，甚至出乎意料地流行起来了。我们构建了Chrome，部分原因是为了解决IE的那些垃圾回收Bug，但也因此催生了了v8，再由v8产生了Node.js。

最后导致今天大多数的Web工具都是用JavaScript编写的，尽管Google习惯用Java构建这种工具。模块系统（UMD、AMD、CommonJS）迅速发展。（随之出现了ES6，并发明了自己的模块系统，但是由于某种原因它与其他所有模块系统不兼容，唉！）

NPM统一了工具和库的共享方式。Webpack可以在开发期间，将模块动态地切换到正在运行的应用程序中。

Google一概没有用到这个技术。Google的那些经验丰富的Web开发人员像是生活在另一个时间线中。我们有像SASS这样的CSS预处理语言，但它不是SASS而且没有人喜欢它。精心设计的块分割程序并不能真正支持第三方JavaScript库，部分原因是这些工具的出现早于JavaScript的库生态系统。

这都只是历史。你可以说我们本不应该这么做，但这么说却无法改变现状。相反，有趣的问题是：接下来我们该何去何从？有几个选择。我的观点肯定是偏向我喜欢的技术。

接下来我们该何去何从

第一个诱人的选择就是放弃眼前的一切，并从头开始建造一个没有JavaScript的新世界。如果我们投入更多精力到GWT（一个将Java编译成JavaScript的Google项目）或Dart（一个将新语言编译成JavaScript的Google项目）或WASM，或者你最喜欢的语言：Clojure？Haxe？还是Elm？那么我们根本不需要担心JavaScript！

作为PL爱好者，我非常喜欢这个想法。我想仔细分析一下这个想法，但是这篇文章已经够长了，而且我认为已经有很多关于这方面讨论的文章了。

作为反驳，我有一些常见的问题：如果采用一种不同的语言，那么第一个问题是，这对于我们现有的数百万行代码没有任何帮助——“用新语言从从头开始重写”等想法在某些情况下是正确的选择，但是如何充分利用Gmail工程师的时间是一个很难的问题；第二个问题是，对于我们想聘请的经验丰富的前端工程师来说，也几乎没什么用。

与重写一切相对的做法是不改变任何东西。您可能会说，公开的JavaScript世界充满了业余和不成熟的代码。一个优秀的工程师总能适应我们特殊的前端方式，我们总能改进或构建更多自己的工具。

我们构建的应用类型（Google搜索页面每天可以获得数十亿次点击）与其他人构建的web应用程序不同，我们的工具既优秀又很有必要性。我非常赞同这种观点。

我认为在权衡利弊的时候，有一种看法认为建立我们自己的工具很有道理，而另一种看法则认为我们已经远离主流，我们的工具是一种负担。

那么争论的焦点是我们究竟处在什么位置，我相信我们不属于后者。我们为LLVM / Clang做出的贡献获益良多，因为我们依赖于C++，但是我们构建自己的LLVM，并不能从中获得更多额外的价值。

我们应该折中

所以，我觉得我们应该折中，这也是我们的团队一直在追求的道路：逐步采用一些合理的外部工具，并弄清楚这些工具如何才能与我们现有的代码库相互合作。

这项任务并不那么有趣，因为我们不会只是单纯地抛弃历史遗留的混乱或者“这次做正确的事情”，但我喜欢更谦虚地思考，不要固步自封。

为了Google的JavaScript世外桃源重回大陆，我们要做的第一步是：采用了一个支持良好的静态检查器：（1）不是我们自己做的；（2）很流行，同时与我们现有的代码相似；（3）旨在搭建通往JavaScript的桥梁；（4）旨在支持大规模的开发，这才是我们定制工具的根本原因。而这个工具就是TypeScript。

Closure编译器的优势在于优化输出，而TypeScript具有出色的用户界面且根本没有优化。因此这两个工具可以互补，并且（有些工作）可以结合在一起。

因为TypeScript已经很好用了——毕竟只有这样我们才会采用它——所以我们获得了许多采用已有语言的好处，比如IDE风格的代码自动补齐，以及能够从StackOverflow获取答案。

留给我们的主要工作是集成：允许我们的应用程序逐步转移到TypeScript，而无需从头开始重写。我们在与Google的构建系统集成时非常谨慎，我们采用了渐进式编译，这对大型应用程序至关重要；而且一个模块中的变更不会影响使用了该模块的API，也不会导致下游模块需要重新编译。

我们与Closure类型/模块系统的集成意味着ES6 TypeScript模块可以导入Google模块系统中的模块，而且保留了（大部分）类型信息。一家公司成功地使用了我们发布的工具，自动将其整个代码库进行了转换，同时保留他们压缩后的输出。

现在Google内部，各个地方都或多或少地使用了TypeScript；如果您使用Google的产品，那么意味着你已经与一些TypeScript代码打过交道了。TypeScript本身就是一系列有趣的折衷方案，它将静态类型的编程语言与自由转换的JavaScript生态系统进行了平衡。

我们工程师也会这么做：我们也会做出有趣的妥协，试图平衡不同的问题。我希望将来可以写更多关于多年来发现的一些有趣的小事。正如刚开始使用TypeScript时我写下的这篇文章一样（http://neugierig.org/software/blog/2016/02/revisiting-typescript.html），我认为TypeScript在设计领域内做出了很好的权衡。