Google前端如何开发

除了 Gmail、Maps、Plus 这样的特例，基本上都是由后端模板生成页面，很少项目使用 JS 来写界面，更少使用 MVC 框架，这点其实在很多公司都差不多，比如某 B 也是一样的，除了地图及广告管家等产品，其它产品基本上都是通过模板生成的。

某 G 的页面是通常是由 Java 或 C++ 语言所写的模版引擎生成的，而且开源出来了，分别是 Closure Templates 和 CTemplate，话说某 B 在几年前也自己写了个 C++ 的模板引擎，但目前基本被淘汰了。

对某 G 来说，「前端」工程师要写 Java 和 JavaScript，而「后端」服务主要是 C++（某些地方开始使用 Go 了，比如这个）。

前面说到招人时都要会 Java，这带来的结果是大多数团队成员更了解 Java 而不是 JavaScript，于是在这种背景下很自然地诞生了 GWT 这个神奇的东西，它在内部很多地方使用，按照内部人士的说法，主要的考虑是：

能自动生成跨浏览器浏览器代码

结构规范，通过编译器就能提前发现很多问题

能使用强大的 IDE 来提高效率（重构、自动完成、方便跳转到定义等）

对于专业做前端的同学，看到 GWT 多半不喜欢，感觉就是多此一举，但如果是 Java 出身的工程师其实是很容易接受的，尤其是对于习惯了 Java 的代码组织方式及强类型语言的人，反而会很不习惯 JavaScript 这种弱类型的语言，觉得太难控制太容易出错了，比如拿到一个变量，在 Java 代码中通过它的类型就能知道它的数据结构，但 JavaScript 就不行了，只能在运行时 console.dir 出来或找相关实现的代码，从我个人体会来看，对于陌生代码，JavaScript 版本的理解难度要明显高于 Java 版本。

话说某 G 曾经弄过一个叫 Wave 的产品，后来产品失败后就将代码开源出来了，我认为这个代码能反应出 G 内部在使用 GWT 时的开发风格，我用 cloc 统计了一下它的代码情况，结果如下：

神奇吧，这么复杂的前端交互应用，只有 1 个 56 行的 JS 文件，而且其实这个 JS 还是无关紧要的，所以你可以理解为什么某 G 只招懂 Java 或 C++ 的工程师了吧。

后来某 G 的 Lars Bak 大神推出了 Dart，在我看来就是用来取代 GWT 的，前面说到的 GWT 优点在 Dart 都有，而且在 I/O 2012 有一个演讲题目是 Migrating Code from GWT to Dart，赤裸裸啊。

另外其实某 G 内部也不是所有人都喜欢 GWT，比如 Plus 就没使用，而是直接基于 Closure 开发，并使用 Closure template。

说到 Closure，就不得不提它的起源：Gmail，在 WebApps 2010 会议上，有篇 PPT 介绍了 Gmail 代码的情况，以下摘抄其中几个信息：

2004 年就有 9400 行代码了，还有个 JS 编译器（Closure compiler 的前身）来压缩代码、检查错误等

2005 年有 22000 行代码，10000 行注释

2006 年有 52000 行代码，23000 行注释，开始使用面向对象，并初步形成 Closure library

2007 年重写，代码达到 90000 行，注释居然有 97000 行（太厉害了。。。），开始出现模块化机制，而且出现了 Closure Templates

随后开始内部使用，并最终对外推出了 Closure 系列工具

演讲人认为 Type-checking is important and possible

有报道说在这个会议中演讲人还透露 Gmail service 也是用 JS 写的，代码有 443000 行

对于这个消息，我不确定是否真实，但确实是有可能，08 年时 Stevey Yegge 也说过某 G 的规范有漏洞，没说 JS 只能用在前端，而且他还真这么做过。

最后插一句我的观点：对于我所处的团队及用户类产品来说，GWT 没有意义，而 Dart 虽然比起 GWT 要好得多，但和 JS 交互实在太麻烦，导致它的使用场景很有限，语法有明显变化，使得难以让大部分前端工程师接受（Lars Bak 就在 I/O 2013 上吐槽工程师太纠结语法，看起来大神在内部推广时肯定遇到不少阻力）。对于类型检查的好处，我个人是比较赞同的，因此我更喜欢 TypeScript 这种增强形方案，因为它可以逐步适应，既有类型支持的优势，又能直接使用现有代码。