雨夜带刀

前言

React 是 Facebook 开源出来的目前比较流行和热门的前端框架，因其基于组件的开发符合当下和未来的前端发展趋势。

React 还引入了 JSX 语法，对于初次接触 JSX 的人可能会感觉有点别扭，但是当你用过一遍之后就会发觉已经对其爱不释手了。不得不赞叹 Facebook 的开发者，为了能让开发更简便，而想出来的牛逼的解决方案。当你深入使用 React，你会发觉整个 React 的设计思想都是令人叹为观止的。

在之前的 前端自动化构建和发布系统的设计（一） 中我有提到过使用 gulp-seajs-combo 合并 JS 模块的问题。在那篇文章中只提供了简单的 demo，当然在 github 上有详细的文档以及测试用例，尽管如此，还是会有人对使用会有诸多疑惑，希望能在看完此文后对使用 gulp-seajs-combo 合并 seajs 模块有更深入的了解。

无论是使用什么样的模块化开发模式，不管是 AMD 还是 CMD，抑或是其他类型的模块化规范，在开发时都会将一个大的应用或功能分割成一些小模块，而到了生产环境，为了能节省 HTTP 请求数，会希望将原来的小模块进行合并。

在开发环境，模块加载器解决了模块的依赖和加载的问题，由于客户端 JS 的使用特性，依赖和加载是绕不开的两个问题，不管你用的是小而美的模块加载器还是看起来很高大上的框架。在生产环境中，对模块按照依赖进行合并，这就是合并工具应该做的事情。

Handlebars 是一款语义化的模板引擎，其模板语法就像是在写普通的 HTML 代码，并且在性能方面也表现优秀。本文将介绍 Handlebars 如何结合 seajs 来使用。

模板引擎的编译和预编译

开发者用语义化的代码编写好模板，然后将编写好的模板再进行编译，这个编译环节是必不可少的。服务端的模板也同样需要编译，只是这个编译环节是在服务器上进行的。

前端模板引擎要么是直接在浏览器中进行编译，要么就先将模板进行预编译，预编译的代码是可以直接放到浏览器中运行的。在浏览器中编译就意味着会有一些编译时的性能开销，如果要追求前端性能的话，肯定是使用预编译好的模板。

Handlebars 提供了支持编译和不支持编译的 2 种版本，不支持编译的 runtime 版本只能运行预编译好的模板，而 runtime 版本的库文件理所当然要小得多。

在开发环境中，要确保开发方便，引用的是支持编译的库文件，而在生产环节中，模板经过了预编译，此时引用的是 runtime 版本。

在 前端自动化构建和发布系统设计（一）中主要介绍了使用 gulp 来构建，本篇将主要介绍发布部分。

URI 的设计规则

先来看一个完整的静态资源的 URI，http://a0.jmstatic.com/5d4f23234a51261e/common.css，这个 URI 由三部分组成，依次为 静态随机资源域名/文件 md5 值/原文件名 。

• 静态资源域名是随机生成的，这样可以在同一个站点中使用多个静态资源域名；
• 文件 md5 值是根据文件内容来生成的，这样能确保其唯一性；
• 原文件名有2个作用，作用1是可以从文件名看出在开发环境中对应的是哪一个文件，作用2下面再说；

前言

前端的业务逻辑和交互效果越来越复杂，代码量也随之越来越大，伴随着越来越大的代码量而来的还有代码的管理和部署的问题。模块化和预处理框架大行其道，新框架的出现让前端的开发环境越来越高大上了，但是部署到线上就越来越费劲了。在开发环境中模块化会将原本的大型应用分割成很多小模块，但是在上线的时候考虑到这些静态资源对 HTTP 请求数和请求体积的开销，很多小模块都需要合并然后再进行压缩。在 node.js 火起来之前，比较常见的处理工具有 ant，但是 ant 是基于 java 的，对于前端工程师来说使用起来很费劲。

grunt vs gulp

node.js 火起来之后，出现了很多用于处理前端静态资源的优秀模块，还有专门用于前端静态资源构建的框架，如鼎鼎大名的 grunt，但是 grunt 由于其基于配置的设计模式和构建模式基于文件的限制，对于复杂一点的构建逻辑配置起来就会比较繁琐。