大规模的前端组件化与模块化
本文根据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，browsery（+debowerfy&brfs），commonjs，sass（用于做css模块化），taskrunner（基于grunt），以及bower。系统在设计上遵循几个原则：
编译时纳入所有依赖去中心化、分布式，比如我们的git repo是分散的，没有一个所谓的core或common的codebase
内置命名和封装的规则
对于上面提到的分界点，Origami是这样处理的：core的部分需要保证在用户环境对JavaScript支持差或不支持的情况仍然能够完成基本内容的呈现、搜索引擎的抓取等。这个分界点在Origami当中通过 if (querySelector in document) 来实现判定。
