谷歌 Web 开发技术变迁史与踩坑史 | NEXT Collections · Google I/O

这是「 NEXT Collections | Google I/O」系列的开篇。NEXT Collections 是NEXT 用户基于产品集的干货分享专栏。Google I/O 期间，我们邀请和聚集了 NEXT 用户中的 Google 工程师、国内 Android 顶尖开发者，为大家分享和呈现关于 Google 的最干货信息与观点碰撞。

文章的作者 CJ 是 Google 八年的资深工程师，现回国创办了在线协作文档「 一起写 」，这篇文章也是他与 geek 范的同事们在「 一起写 」协作完成的。点击 NEXT 产品集「Google 开源项目」，完整查看文中提到的技术与开源项目。

过去十几年来, Web 开发技术从最初的纯 HTML 到 CGI、PHP / JSP / ASP、Ajax、Rails、Node.js，已经发展到了一个非常成熟的阶段。去年的 Google I/O，谷歌开发者中心推出了关于 Web 开发的最佳实践手册；而今年的 Google I/O ，「The Next Generation of Mobile Web」依然是其中的一个重要议程。

不过，前人栽树，后人乘凉。现在大家拷贝的代码可不是自己从土里自己长出来的，而是技术大牛一行行敲出来。即便是谷歌这样的互联网巨鳄，在 Web 开发上也经历过无数的努力和踩过一个又一个的坑。今晚 Google I/O 正式开启之前，我就给大家讲讲这些事儿，聊聊从 Desktop 时代到今天的 Mobile 时代，谷歌 Web 开发技术的变迁、踩过的坑。

| Gmail、Google Map : 世界疯了两次

大家知道,最早期的 web 开发指的就是 HTML，CSS，JavaScript，很多刚毕业的学生就会说，“切，会写 HTML，JS， CSS 不算写程序, 会写 C++ 的才算”， 这可大错特错了。你们想想，写一个 C++ 程序只需要会一种语言，写个 Web 应用得学三种语言，而且这三种语言还以一些神秘的、很多时候还没有文档的奇怪方式联系在了一起，再加上某些西北角的公司在里面再捣捣乱，导致 Web 应用非常的难以维护，直接的后果就是 99% 的应用都是简单的网页加上一点点可怜的逻辑，完全无法取代桌面上的应用。

这个时候，英雄出现了。Google 在 2004 年愚人节那天发布了一个叫做 Gmail 的东西，当时 email 的容量只有可怜的 10MB 或者 20MB，Google 突然说提供 1GB 的邮箱并且不断增长，于是，全世界疯了。可是在大容量的背后，大家发现原来 Gmail 不仅仅只是大，而且让你觉得你在使用一个桌面的应用，而不是一个以前传统的网页的应用。 所以可以说，Gmail 是 Web 开发的一个里程碑，第一个大规模部署的 Ajax 的应用程序。

紧接下来的一年，也就是 2005 年的情人节前后，Google Map 神奇般地出现了，世界再一次疯了。所有人都觉得不可思议，原来网页的程序可以做得那么酷炫，而 2000 年左右科技泡沫鼎盛时期的那些网站是多么的可笑。当时 Map 的组里面有 2 个人很值得一提，一个叫 Lars Rasmussen 的澳大利亚人，一个叫 Bret Taylor 的美国人，后面我们会慢慢的提到。

| 重写 Gmail

在开发 Map 和 Gmail 的过程中，Google 的工程师逐渐意识到一个高度结构化的JavaScript 库的重要性。因为逻辑越来越复杂，代码量越来越多，功能也越堆越多，之前写得那些代码已经根本满足不了不断变化的需求了。 于是伟大的工程师们做了一个 Googler 经常做的决定：我们重写吧。

一个伟大的重写 Gmail 的计划逐渐张开了，也就是今天大家看到的 Gmail 的前身。在整个重写的过程中，一个高度独立、结构化的 JavaScript 的库被抽象出，这就是可能很多前端工程师们知道的 Google Closure。用今天的话来说，Closure 不是一个简单的 JavaScript 的库，他是一种方法论，一种情怀，所以任何拿 jQuery 和 Closure 相对比的言论都是一种对 Closure 的侮辱。Closure告诉大家，大家应该像写 java 一样的去写 javaScript，分清楚什么是一个类，什么是类的成员变量，什么是成员方法，什么继承，什么是接口等等...所有你熟悉的面向对象的概念都可以在 Closure 里面找到。Closure 的出现极大地改变 Google 内部写 JavaScript 的效率，导致复杂的 Ajax 的应用如雨后春笋一样在 Google 内部迅速出现。

| 聪明人太多的产物：奇葩技术 GWT

如果让 Google 的工程师们自己找 Google 一个不好的地方，一定有一点，那就是聪明人太多，没法管理。就在 Gmail 如火如荼重写的时候，另外一个团队在悄无声息的做着另外一个类似的努力去改变 Web 开发，那就是 2006 年发布的 GWT（Google Web Toolkit）。这是一个无比奇葩的技术，程序员写的代码是 java，出来的是 JavaScript，就像你吃的是草，挤出来的是奶一样。这个技术的根本目的和 Closure 是一样的，就是为了让程序员用写 java 的方式去写 Web 应用，只是他的方式更直接，连 JavaScript 都省了。其实原理也很简单，就是通过编译器在编译阶段把 java 转成了 JavaScript 代码。可是，这个技术有一个致命的缺点：你想想，要有多麻烦才能在浏览器里面调试一堆由编译器生产的JavaScript 代码。于是无数的各种附加调试技术出现，告诉大家怎么去简化 GWT 的调试，但是都没有解决根本问题。GWT 的最大的好处就是如果你的网页是由标准的控件组成的，比如输入框、选择框、多选等，那么 GWT 会极大的简化你的代码量.就是因为这个好处，GWT 一直活到了今天，因为 Google 最赚钱的广告系统的前端是就是用 GWT 写的。可见，计算机语言的世界也是看爹的哈哈。

2007，2008 貌似很平静，Google 也没发布什么惊人的、大的前端产品和框架。事实上，他们并没闲着。Google 在那两年期间做了几个重要的收购，奠定了后面著名的 Google docs 的基础。

2009 年，在 Google 内部雪藏了很久的 Closure 库终于开源了，同时开源的还有一个对应的叫做 Closure Compiler 的东西，一般人理解 Closure Compiler 不就是另外 jQuery Minifier 嘛，其实可没那么简单，Closure 的 Compier 是可以真的理解你的 JavaScript 代码的类型的。通过一个叫 JsDoc 的注释形式的语法，你可以完全地把  JavaScript 当做是一种强类型的语言来写，并且有一个编译器来帮你查错。在强大的工具面前，jQuery 被无情地碾压。在接下来几年，Google又陆陆续续的发布了对应的 Closure 的模板语言，和对应的 Closure Stylesheet 编译器，于是 Web 的三件套，HTML + JS + CSS 在 Closure 的世界里都有了对应的工具，在 Google 内部,大部分的前端项目也都是基于这套工具来开发的。

与此同时，GWT 的小组也没闲着，一方面更好的支持 Google 最赚钱的广告系统前端；一方面默默的憋了一个超级大招 -- 大名鼎鼎的 Google Wave。对，Google Wave 是用 GWT 写的，Wave 的 founder 就是我们前面提到的 Map 的创始人 Lars 。

| 又把最赚钱的广告系统重写了一遍

2011，2012 的 IO 上，关于 web 开发的主题很多都是基于 GWT 、Closure 展开的，一直风平浪静地到了 2013 年。但与此同时，Google 内部已出现了一股暗黑势力，悄悄地开发了一个完全颠覆式的前端框架 -- AngularJS 。它，就是以HTML 标签起始符形状命名的 AngularJS，简称 Angular。颠覆在哪呢？Google 的 web 前端开发框架基本采用著名的 MVC (Model-View-Controller) 结构，有效地分离数据模型和最后显示的视图，使代码更清晰、更容易维护。早先的 MVC 大都是在服务器端实现的，包括先前提到的 GWT 神器。但是 AngularJS 不一样，是一个完全在客户端也就是浏览器里的 MVC 框架。这个框架在 HTML 中标注新的属性，运行时用 JavaScript 动态解析和绑定数据关联，简化了 web 应用尤其是单页应用 (single-page application) 的开发。不少数据双向同步逻辑甚至不用手工编写 JavaScript 就能实现了。更重要的是它制定了一整套前端组件的开发规范。虽然各种繁杂的条条框框让它无论在 Google 内部还是开源社区都备受微词，但它还是迅速获得很多企业的青睐，近几年来以异军突起之势成为众多公司招募前端程序员的一项标准需求。于是疯狂的程序员们又 疯了，开始把很多陈旧的系统用 Angular 重写，包括前面提到了那个最赚钱的广告系统前端。甚至Angular 一出来的时候就有人预测，Angular 就是早期的 HTML6 。

| 异类语言的诞生

说到这里，不能不提一个异类语言了，叫做 Dart 。这个 Dart 可是出自名门，是由 V8 的首席程序员 Lars Bak 在他工作之余发明的， 他一边改善 V8 的性能，一边琢磨如何能突破 JavaScript 语言本身诸如弱类型等限制，让 web 程序执行速度更上一层楼。他最后决定，干脆摆脱 JavaScript 的束缚，重起炉灶设计一门全新的、为新时代 Web App 专门打造的语言 -- Dart。

在了解 Dart 前，简单科普一下同父同母的兄弟 V8。 Google 的 Chrome 浏览器当年发布时以其远超 Internet Explorer 和 Firefox的网页渲染速度震撼了世界。其中一个核心优势就在于全新的 V8 JavaScript 引擎。当竞争对手还在吭哧吭哧解释执行 (interpret) 网页中的脚本时，强大的 V8 引擎采用即时编译 (JIT) 技术把 JavaScript 的运行速度提升到了一个全新的层次。在之后的几年里，各家浏览器厂商纷纷效仿，推进了整个 Web 平台的发展。目前深受追捧的 Node.js / io.js 其实也都是 V8 开源后的衍生产品，造就了一个前后端用同一种编程语言的新兴开发生态。

Dart 语言借鉴了广大程序员熟悉的 Java 语法，支持面向对象、单继承、interface、泛型、非强制的类型标记等语言特性。Dart 的虚拟机在 V8 大牛的打造下性能当然也是超强的。Dart 程序还能被编译成 JavaScript，运行在没有 Dart VM 的环境中。

然而，Dart 从发布日起一直倍受争议和质疑。它被认为是一项分裂 web 之举，而且长期以来没有得到任何其他浏览器厂商的支持。2015 年初，Google 宣布取消将 Dart VM 绑定在 Chrome 浏览器里的计划。不过这并不是 Dart 的死刑判决。Google 仍然支持并使用 Dart 开发大型 web 应用，因为比起 JavaScript，Dart 更能提高开发效率和保证代码质量。

综上，大家可以看到，web 在开发上两个趋势，第一个是从脚本语言层面去改善代码的质量，提高效率，第二是从 web 标准入手，提供更多抽象的模块化的组件，让编写 web 应用更加容易。

而说到第二点，不得不提提 Google 的一个项目叫做 Polymer ，如果你们去 Polymer 的网站，你会发现 Polymer 的口号是「leverage the future of web platform now」。 的确，Polymer 是一个库用来实现 Web component 的，而 web component 是 W3C 关于下一代  HTML 的一个标准，这可是根正苗红的一个项目。可以说 Polymer 项目的进展某种程度上就代表了下一代 HTML 标准制定的进展。让我们一起期待在本次 IO 上 Google 会对 Polymer 做出怎样的更新吧。

「 NEXT Collections | Google I/O」系列将持续更新，请保持关注。你也是一枚 Googler 或 Android 开发，并且有话要说？对文章观点有质疑？想加入 Google 工程师和 Android 开发大牛的线下讨论？欢迎邮件xinyuan@36kr.com。文章作者的新项目「一起写」也在招聘 geek 范的同事，欢迎简历快递至 CEO 直聘邮箱： c@yiqixie.com 。

原创文章，作者：馨苑