为什么PHP中ThinkPHP有做类似模板引擎的东西？smarty也是？这些到底有何用？

我是真没发现它们的用处在哪里？分离了前端和PHP的依赖？HTML文件确实没有写PHP代码了，但是却有smarty或者Thinkphp的模板引擎代码在里面，PHP程序员要学，前端人员也要学，这不是反而增加了开发时间和开发难度？吃力不讨好？而且用了模板引擎势必要在PHP层面对HTML代码进行字符串替换解析，都知道字符串替换是很耗性能的，费时又浪费性能的。仅仅为了分离前端跟PHP，我觉得这相当不划算。是否我对其作用（仅仅为了分离前端和PHP，方便各司其职）理解有偏差？请赐教！

回复内容：

项目小，一个人折腾的时候，怎么快怎么来，构建MVC，解耦页面数据代价比较大，所以你会说没用；
项目大了，人多了，代码复用、规划、编码规范、人员沟通的成本急剧上升。
把每个人的工作连接起来，需要规则；
减少条条框框的束缚，大家各司其责专注自己的工作，避免互相干扰，才能提高效率。

回到你的问题。我分解成下面四个点：
1. 为什么要出现模版引擎？
2. PHP本身不就可以起到直接在HTML结构里面嵌逻辑脚本了吗？
3.为什么又演变出独立的语法
4.性能开销怎么考虑

1. 为什么要出现模版引擎？
Z：请设想有两个人合作一个项目，一个负责页面部分，一个后台数据。（其实就是前端与后台）
那么他们应该专注在自己负责的部分。
以页面的同学为例，他应该只关心数据如何呈现，如何交互，如何将用户数据传给后台。那么目前业内的实践经验是，前端与后台约定好页面参数及接口协议，即可各自独立开发。

2. PHP本身不就可以起到直接在HTML结构里面嵌逻辑脚本了吗？
Z：前面说到，合作中应该各自专注自身工作，避免互相干扰。页面的同学直接在页面模版中有可能操作PHP脚本中的全局变量、属性、方法；后台的同学在给页面传值后有可能意外修改到参数。。。这些都是因为他们的环境没能隔离开的缘故。
那么比较好的方案就是给页面模版一个独立的参数作用域，将页面参数单独传递进去。

3.为什么又演变出独立的语法
为了减轻页面开发的学习负担，也让页面更加直观。请比较：

{{ innerHTML }}

使用MVC，在View层我也觉得用原生的PHP代码比模板引擎更高效，这个跟项目的大小无关，PHP本身就是最优秀的模板语言。 这些模板系统是以前为了代码和样式分离遗留下来的。现在普遍都是 MVC 架构，所以基本没用了。

PS：小系统也应该用 MVC，机器比人工便宜多了，开发效率最重要。 一般有这种疑问的多是代码量偏小的。
分离是为了便于维护，牺牲部分开发效率用以便于日后维护也是很正常的事情吧。
如果是你，你愿意维护一个PHP与HTML全部写在一起的乱糟糟的系统，还是愿意维护一个MVC三层分明的项目？
学习不是什么大问题，大多数框架的上手速度都不慢。而且对于一般框架来说，他的首要解决的问题之一就是快速开发，开发效率不是问题。
运行效率有损耗是正常的，因为mvc这种模式，本身就是一种牺牲效率提高稳定性的方案。 用ThinkPHP开发已三年！简单说一下感受
（1）第一年：因为懒得学ThinkPHP内置模板引擎语法，就直接使用自己熟悉的Smarty；
（2）第二年：因为平时收集的不少ThinkPHP源码，使用的是内置的ThinkPHP模板语法，没办法，就把内置的ThinkPHP引擎看了一遍，其实就是一二天事，基本上与Smarty没有太大的区别，做几个实例就掌握了；
（3）第三年：有一次在做一个项目时，需要在模板中使用原生的PHP字符串函数做一个简单替换，结果突然发现，居然不会写了，要去查手册！
太可怕了，这在二年前简直不敢想象，以前闭眼都不会敲错。
所以，各类模板引擎，在方便程序员的同时，也使大家对原生的PHP语言变得陌生了。
所以现在，拿到项目开工前，我会直接在Application下的公共配置文件中

     'TMPL_ENGINE_TYPE'      =>  'php',     // Think模板引擎使用原生PHP
     'TMPL_TEMPLATE_SUFFIX'  =>  '.php',     // 默认模板文件后缀

代码和样式分离，当然，现在一种趋势是直接js了，php都不要 不懂，只知道我以前一个月开发的项目，现在两周或者一周搞定。 框架主要是为了我们这些民工服务，还是老老实实的写代码把，有本事自己也写个框架出来刷刷