本文根据Andrew Betts在QCon北京2014大会上的主题演讲内容整理而成。
Andrew Betts是英国金融时报实验室（FT Labs）的负责人，同时也是一位PHP和JavaScript程序员。他的团队致力于研发试验性质的Web技术并发布相关产品——比如金融时报Web App. 在加入金融时报实验室之前，Andrew创建了Web咨询公司Assanka，为诸如News International, The Economist Group and the FT这样的客户打造创新性的Web项目。
今天的话题是大规模的前端组件化与模块化。首先，先介绍一下FT在研发方面面临的挑战：
不同的服务如搜索、内容、广告、应用，都是由不同的团队来开发，团队之间的沟通较少。造成的结果就是，整个服务的灵活性和可维护性越来越差，系统变得越来越复杂之后，新人进来的学习难度很大。随着整个软件开发生命周期变得越来越复杂，新功能的集成变得越来越难；更糟糕的是，随着移动设备的流行，研发团队不得不把同样一套逻辑分别在桌面端和移动端各自实现一次。这也是全世界的软件研发团队面对的挑战。
为了应对这些问题，FT Labs开始推行几条前端的开发理念，目前已经获得比较好的效果。
***条理念是：“活的”风格指南。“活的”风格指南也可以理解为代码即文档，文档即示例。这里举一个例子，比如Facebook的React项目。你去看React项目的介绍页，这个页面本身就是一个React的推荐实现。
当然像React这样的项目，说明页面的实现是一个方面，此外还有另一个重点：组件化的开发方式。正如React不是一个框架——它提倡的是无框架，因为任何框架的引入都会增加额外的复杂度和学习成本。组件（Web components）则不同，它一旦开发出来，就是一个随时可以很方便的调用的功能；而且，不同的团队可以同时进行不同组件的开发而互不干扰。Web组件是一个正在快速发展中的特性，目前浏览器对它的支持还不***，不过也就是1-2年的时间，现在应该要为未来做准备。对于Web开发而言，向前兼容要比向后兼容更加重要。
组件化的使用在我们处理历史网站的过程中节省了大量的工作。FT有超过600个域名需要维护，很多网页从互联网时代早期就开始运作。对于这些遗留页面，要全都重写以适应新的浏览器是代价高昂、不值得的，但你又要尽可能的让它们能够正常显示。我们用组件来进行局部替换以解决这个问题。比如某个老页面上有一个图库展示，现在的浏览器不能显示了，你就批量把这种老旧的图库展示代码替换成新的图库组件代码即可。
另外还有一点很重要，就是拥抱模块化，避免在代码中嵌入依赖关系。做开发这行儿一个很重要的觉悟就是：你要相信，你现在写出来的这些代码，等两年之后，你自己都会不想去看它。模块化会让你的生命更简单。
对于浏览器兼容性，正如刚才所说，我们的建议是跟着***的浏览器功能走。不过这里面也有一个分界点，就是所谓core experience和primary experience的分界点，并尽可能的将分界点向扩大core experience的方向推进。对于NoJavaScript的处理，我们的经验是，基本上所有人的浏览器都会支持JS的，尽可以放心大胆的用。
说到这里，我要进入今天的重头了，那就是FT的Origami这个项目。Origami这个项目要做定义的话可以说是一套规范，是一组文档化的***实践，同时搭配Registry这套工具，以方便所有人以***实践建立规范统一的服务和组件。
这套系统的构成大体上包括一套closure compiler，browserfy（+debowerfy&brfs），commonjs，sass（用于做css模块化），taskrunner（基于grunt），以及bower。系统在设计上遵循几个原则：
- 编译时纳入所有依赖
- 去中心化、分布式，比如我们的git repo是分散的，没有一个所谓的core或common的codebase
- 内置命名和封装的规则
对于上面提到的分界点，Origami是这样处理的：core的部分需要保证在用户环境对JavaScript支持差或不支持的情况仍然能够完成基本内容的呈现、搜索引擎的抓取等。这个分界点在Origami当中通过 if (querySelector in document) 来实现判定。
Registry作为工具，会做以下几个事情：
- 扫描所有已知的git服务器
- 给版本标签建索引
- 给每个模块的每个版本做build
- 把每个模块的所有版本收集、整理到一个模块页面上
Registry可以说是我们Web服务的一个黄页。我们把这个黄页放在公开的互联网上，这样所有人都可以上去协作，每个人都可以查看每个组件的每个版本，它们的说明和相关文档，实现的样板等。如果有的功能还没做完或者没启用，可以打上一个not implemented的flag。
大家可以在Registry上随意查看我们的各个组件，比如header，footer，调色板，按钮等。这些组件调用起来很简单，以调色板为例，只需要
- <link rel="stylesheet" href="http://build.origami.ft.com/bundles/css?modules=o-colors@^2.3.8" />
- <script src="http://build.origami.ft.com/bundles/js?modules=o-colors@^2.3.8"'></script>
这样的两行代码即可调用任意模块的任意版本。
我们的build服务可以按需build不同模块的任意组合，之后还进行打包、压缩、优化等处理并通过CDN分发（经过了GZIP处理）。调用的时候可以指定调用指定的版本，或者自动调用***版。有了这套系统后，开发者创建原型变得非常简单了。
下面我介绍一下我们遇到的一些零碎问题，以及我们是如何处理的。
首先，有关polyfill的加载，如何才能让polyfill仅在需要的时候才加载？我们的处理办法是在模块的metadata中进行声明，哪些是required，哪些是optional，以modernizr测试名来进行控制。
然后，如何在支持JS但是支持的不好的浏览器中显示noscript当中的内容？我们的办法是定义一个o-nojs-fallback类的div，通过类的visibility来控制呈现。
对于hover的处理，我们用了一个o-hoverable的组件来控制。
对于资源加载，为了确保每个组件都知道其他资源的URL地址，我们专门有一个o-asset组件。
***想说的是，将我们的这些工作公开在互联网上，我们从中收获了很多。
