无可否认，我已经成了 Google 最忠实的 fans; Google 这次又帮我找到我想要的东西，我又一次对 Google 崇拜的五体投地。

我一直在搜寻一种模板系统，它的速度要快，功能要强，用起来要比较简单。

一开始，我找到了 django 模板系统。和同类模板系统相比，它的速度是最快的，当然比用 C 写的模板系统稍慢一点，但已经非常不错；功能当然非常强，你甚至可以自己定义语法；用起来确实也非常简单。

但我也有追求效率的毛病，如果存在和 Django 模板系统类似，但比 Django 模板效率更高的模板系统，我会马上移情别恋。

这时，我发现了 Jinja 模板系统，它拥有 Django 模板系统的语法，并且具有更高的执行效率。原因很简单，它将模板代码转换成了可执行的 python 代码，并且有相应的 Cache 策略，速度自然要快很多。

Jinja 系统已经非常不错，但可惜的是，我又发现了 Mako 模板系统，它直接用 Python 代码来书写模板里面的逻辑，和前两种模板系统的哲学(Philosophy)完全不同，它的哲学是:

    Python is a great scripting language. Don't reinvent the wheel...your templates can handle it !

作为一个 Pythoner，我完全赞同，Jinja 也被我无情的抛弃了。


综上看来，Mako 才是我的首选，不过问题又来了。经过我观察，在 CGI 中，模板的替换以及结果输出这两部分功能所消耗时间占整个 CGI 处理时间的比重非常的大，通常都占 50% 以上，有的时候甚至更多。我可以优化模板替换部分的效率，但完全没有办法对模板输出部分(IO)的效率进行优化，效率提升空间非常有限。

这的确是很令人沮丧的事。不过我想如果要是有一种 Javascript 的模板系统的话，应该可以解决上面的问题。

于是，借助伟大的 Google， 我又找到了 JST(from trimpath), 它的基本原理是将模板系统转换为实际的 Javascript 代码，和Jinja 的原理类似，只是它是在客户端实现的，生成的是 Javascript 代码而已。不过它的缺点是，模板解析是在客户端进行的，多多少少会影响效率；支持的语法并不太多，和其它的模板系统相比，功能并不算强大，不支持双重循环(可以自己实现)；貌似是我的要求太高了，其实它还是非常优秀非常具有可用性的。

受 Jinja 模板系统的启发，我打算为 Jinja 编写一个 Javascript  Translator，可以将模板代码编译为 Javascript  代码。事实上，这是非常可行的，它的官网上也透漏了下一个版本中开发这个 Javascript  Translator 的消息。 我很早就开始着手这一 Translator 的编写工作，目前基本可以出一个 demo 了。 Jinja 还是很值得继续关注。

不过我又很快找到了 genshi2js，它可以将 genshi 模板转换为实际 Javascript 代码, 虽然它仅仅支持 xml 格式的模板系统，但我还是很有兴致的试了一试。生成的 js 代码还是非常不错。不过它要依赖一个叫做 MochiKit 的 Js 库，这家伙比较庞大，有 110k 左右(未压缩)，如果可以压缩到 40k 以下的话，还是有一定的可用性的，有待进一步研究。

偶然间，我发现了另外一个 Javascript 模板系统， 他和 Mako 的哲学类似，直接用 Javascript 来写模板的逻辑，它没有名字，因为他实在太小了，仅仅有30行左右，Blog 作者仅仅用一篇 blog 对它进行了介绍，跟贴者无一不说 cool，它就是我想要的。

我找到了理想中的模板系统。