现在有很多 PHP 模板引擎，并且有不同的模板语言，我一直想不通这样能带来多大的好处，所以我想听听大家的意见。
回复内容：
以前 PHP 的 OO 特性不太好，没有一些优雅的技术手段来将应用逻辑和展示分开，所以发展出了很多模板技术。但现在得益于对 OO 特性的支持，MVC 架构的流行，已经可以丢掉模板引擎了（基于历史原因除外）。Zend Framework 更是直接推荐使用原生 PHP 脚本作为模板引擎，因为 PHP 本来就支持代码与 HTML 的混合书写，同时开发者也更不需要学习新的模板语法。
以前对模版引擎，我也觉得没多大意义，毕竟这事php自己也可以做的很好
但看了twig这款模版引擎之后，我的观点有了些许变化
这款模版引擎在我看来最大的好处就是可以提高套模板的效率
简洁的语法，常用的标签、过滤器、函数，又方便扩展。总之，套模板再也不用写那冗长的php代码了。
要是php也能出个coffeescript就好了。
MVC分开的话，V已经没有意义跑模版引擎了，原生最好。
以前主要是代码分离，方便前端开发。
个人认为模版引擎对于php还是有必要的。
- 安全，比如默认转义输出
- 规范，防止团队中有人在视图中写大量的逻辑代码
- 性能，据说可以提高性能
- 可读，个人认为twig或者laravel的blade引擎比php可读性好
个人一直持反对模板引擎的观点。
主要是PHP本身已经可以实现模板引擎的功能了。或者说PHP本身就是一个模板引擎。至于给非后端人员使用，其实这事也有点牵强。确实直接使用PHP书写模板容易引起一些不规范的操作，但是这事其实是靠规范约束的，不是靠技术框架约束的，几乎所有的模板引擎都提供了运行原生代码的能力，页面开发者遇到绕不过去的点仍然会使用原生的PHP代码，然后一样可以埋雷。
良好的规范、共识和review机制来解决这类问题更有效。PHP本身就是一个非常随意的语言，你可以在任何地方取得很多模块本不应该做的事。MVC为了解耦，但是仍然很多人在model和view里读$_GET，在controller甚至view里写sql。在controller和model里写html。这种事一个MVC根本搞不定，否则这个MVC就是一个不具有普适性的MVC了。
综其原因，原生解决不了的问题，模板一样解决不了，而且还要增加学习成本和开发成本，承担不易调试的麻烦，模板引擎本身有bug的风险，多解决一个依赖的成本等等。
模板设计的意义也是目的就是为了程序逻辑与页面展现分离，便于程序员和美工分工协作而又不会互相干扰。
然而早期的PHP模板实际上是按照程序员的思维逻辑产生的一套机制，在这种机制下，包括在现在所谓的“原生”机制下，页面美工仍然需要面对包含着大量代表程序逻辑的html。不能算作是彻底的分离。
要说意义有多大，相对于曾经的ASP社区，PHP社区至少一直在努力探索着这一Web开发的核心问题，推动着这一问题的不断思考和挖掘。
要真正搞好Web开发的MVC分离，不能只站在程序员的角度思考问题，必须考虑Web开发的全程工作分工，分工清晰了，分离的方案就容易确定。
