ClosureTemplates(1-1)：动，还是静？

第一章 前端模版与模版

第一节 动，还是静？

静态模版 vs. 动态模版

前段时间，在微博上问过@玉伯也叫射雕 他们在项目中为何使用动态模版引擎，而非静态模版。

@中中-Yorkie:

我觉得最大的优势应该是模版的粒度更小，与page解耦等等。

@玉伯也叫射雕:

不是很明白，粒度不是由开发者决定的吗？没在电脑前，待会去具体看下。

@中中-Yorkie:

回复@玉伯也叫射雕: 由开发者决定是没错，不过现在动态模版的做法都是把模版定义写在一个script标签，或者是类似formt形式的js的String对象中，而closure真正把模版定义独立于page，从而和页面解耦。http://t.cn/zlFv0f7 网址在这里。

@玉伯也叫射雕:

回复@中中-Yorkie: 不是这样的，handlebars和mustache等模板引擎也允许将模板写在单独的文件里，比如 xx.tpl 文件。

看到这里，我去反复浏览了handlebars/mustache的文档，不过始终未发现玉伯提到将模版文件写在单独的文件中。后来反复思考，觉得玉伯所说的是使用XmlHttpRequest对象去获取xx.tpl，使用模版引擎编译其响应后并缓存在浏览器中。

以上的实现方式确实可以实现模版与页面(Page)或组件(Component)的解耦，降低模版的粒度等级。

现在再来对比动态模版与静态模版，从性能与维护两个方面进行对比，在进行对比之前，需要先详细分析一下模版引擎的工作方式。

第一代模版引擎，其实现方式很简单，模版引擎只负责将模版字符串编译成输出字符串。 第二代的动态模版引擎加入了缓存机制，在编译模版与输出字符串中添加缓存，该缓存为一个函数集合，每次对模版的请求，先看该模版是否已有缓存，这样模版性能较之第一代模版引擎就有了质的飞跃。

这里要加以区分几个概念：

• 模版字符串：原始的模版文件，包含HTML、CSS、模版名、传入参数等，在模版文件或Script模版块中定义。
• 模版函数：模版第二代/静态模版才引入的概念，即编译后的模版字符串在浏览器中的function表示。
• 模版请求: 对其中一个模版函数的调用，并返回对应的HTML字符串。

下面是动态模版与静态模版在性能与维护方面的对比：

性能方面，静态模版只是将模版字符串转换为模版函数的过程在Web服务发布前就缓存在一个服务器端的文件清单中，浏览器在执行模版请求时，将从服务器端获取模版函数，而非直接的模版文件/字符串。不过动态模版只是在模版的第一次请求时，在编译上花费一定时间，在稍后的执行过程中，与静态模版在性能方面没有任何差别，因此性能方面上的差距可以就此忽略。

在维护方面，谷歌官方给予Closure的对比如下：

In contrast to traditional templating systems, in which you must create one monolithic template per page, you can think of Closure Templates as small components that you compose to form your user interface.

意译为：在传统的模版引擎中，使用者需要为每一个页面创建一系列模版，而与之相比，Closure Templates能让使用者将模版作为一个组件，然后在相应的页面中对不同的模版进行组合。(Closure Templates官方文档的翻译将从第二章开始)

其实也就是我开头所提到的实现页面与模版的解耦。不过玉伯也已经提到了这种解耦也能在动态模版下实现。

因此就目前而言，维护方面，似乎也没有非得使用Closure不可的原因了。

事情到此结束了吗？

不，事情并未结束，这也是Closure Templates系列的原因，我决定彻底地去了解Closure Templates项目，以求得去探究静态模版作为主流模版的一种可能性。

下一节会对主流的动态模版的源码及其实现方式进行简单的介绍，在整个Closure Templates项目介绍完后，还会更加细节性地做出他们的对比工作