How to choose template engine

前言

后端渲染页面的开发方式目前还占据着主导的地位，虽然像Backbone、Angular、Reactjs等技术很火，但是在国内的普及和应用还远远不够。单页，前端渲染页面的方式想要成为主流还有很长的路要走。在我接触的语言中，后端开发的模式基本以MVC为主，V当然所谓的View了，如Java的Jsp、Velocity、Freemark，再如Node的Ejs、Jade、Handlebars等等，可以说不同语言对应很多的模板引擎，那么我们该如何选择模板引擎呢？我从实际开发的维护性来谈几点。

Layouts

使用layouts可以抽出我们页头的公共代码，使我们只需关注单个页面的内容。一般的Html页面都是这样的

<!DOCTYPE html>
<html>
<head lang="en">
    <meta charset="UTF-8">
    <title>title</title>       
    <link rel="stylesheet" href="css/bootstrap.css"/>
    <link rel="stylesheet" href="css/style.css"/>
</head>
<body>
<div class="container" id="container"></div>
</body>
</html>

如果不使用layouts，每个页面我们都得复制一遍上面的代码，然后改变body里的内容，如果有十个页面我们就得复制十遍，更别说复杂的应用了页面都是几十往上。想想这样的情景：你维护着没使用layouts的应用，大概一百左右的页面吧，有一天需要在header里加一个meta标签...别说做了，想想我就想吐了。使用了layouts维护起来就像这样的

#default.xx
<!DOCTYPE html>
<html>
<head lang="en">
    <meta charset="UTF-8">
    <title>title</title>       
    <link rel="stylesheet" href="css/bootstrap.css"/>
    <link rel="stylesheet" href="css/style.css"/>
</head>
<body>
    {body}
</body>
</html>

#index.xx
<div class="container" id="container"></div>

Partials

partials和layouts的核心都是抽出相同的代码，便于维护。比如页面有一个公共的footer结构，98%的页面需要这个结构，剩下的页面不需要。不使用partials的话，就看看哪些页面需要，然后后一个个复制粘贴，好不容易复制完了，设计跑来说：不好意思哈，刚footer里一个标签使用错了，把span改成div。丫的还得一个个去改，累死累活完成了，设计又跑过来了：那啥，还是改回span吧。估计那会儿不管是谁，心里都会默念草泥马。大把的时间都浪费在复制粘贴反复修改上面了。使用了partials，需要footer的页面就引一下，就像这样

#footer.xx
<div>footer</div>

#index.xx
<div>content</div>
{include footer}

这个时候footer里随便改啥都轻松搞定，因为只需要维护一份代码

Block

Block可以理解为占位符，例如上面的layouts default.xx只有一份代码，title是固定的，那么渲染出来每个页面的title都是相同的。实际上不同的页面title是不同的，那么怎么办？有人会说了，title通过后端传递值。我个人觉得页面级的内容最好不要丢到后端去维护，会造成后端代码的冗余，不能为了渲染而渲染。这个时候我们就需要Block了。

#default.xx
<!DOCTYPE html>
<html>
<head lang="en">
    <meta charset="UTF-8">
    <title>{title}</title>     
    <link rel="stylesheet" href="css/bootstrap.css"/>
    <link rel="stylesheet" href="css/style.css"/>
</head>
<body>
    {body}
</body>
</html>

#page1.xx
{define title 'page1'}
<div>page1 content</div>

#page2.xx
{define title 'page2'}
<div>page2 content</div>

其实就是占个坑，然后在具体的页面里指定内容。

Marco

在模板中调用工具方法，举一个最常见的例子，日期格式化，如果在模板中使用不了工具方法。那么我们就得在后端的逻辑代码中先格式化时间，虽然能抽出一个公共的方法调用，但是我还是觉得不能为了渲染而渲染，将这些渲染逻辑丢到业务中。如果模板支持宏，拿上面的例子来说就像这样

#index.xx
{format time 'YYYY-MM-DD'}
<div>page1 content</div>

Set

前面四个内容我觉得是一个模板引擎的标配，随便少了哪样，都会使维护性变得更差，除非有其他类似的替代方案。至于现在的set其实就是可以在模板中声明变量，并可以进行简单的逻辑判断，变量声明这个功能很多模板是不支持的。那么有什么具体的作用呢？拿上面的footer的例子来说，虽然只有2%的页面不需要footer，我们仍然没办法将footer放进layouts中，因为放进layouts中意味着所有的页面都出现footer，当然了你可以说服你的产品经理或者交互工程师，要求所有的页面的都添加footer。可惜这样完美的情况是少数的，我们还得在98%的页面中添加下面一段代码

{include footer}

如果哪天footer改名了，你知道怎么做了吧...如果模板引擎支持变量声明和逻辑判断，那么可以试着这么干

#default.xx
<!DOCTYPE html>
<html>
<head lang="en">
    <meta charset="UTF-8">
    <title>{title}</title>     
    <link rel="stylesheet" href="css/bootstrap.css"/>
    <link rel="stylesheet" href="css/style.css"/>
</head>
<body>
    {body}
    {if !noFooter}
        {include footer}
    {endif}
</body>
</html>

#sb.xx
{set noFooter=true}
<div>劳资就不要footer</div>

顿时妈妈再也不用担心文件改名了。

小结

撇开性能暂且不谈，无论什么样的模板引擎，都应该大大简化我们的工作。如果使用了模板引擎，对页面管理和代码组织毫无用处，那离死也就不远了！

How to choose template engine

前言

Layouts

Partials

Block

Marco

Set

小结

TTFB

引用和评论

Change Detection And Batch Update