我想知道哪种方法更快，在HTML文件中使用纯PHP或使用模板引擎，如Smarty,Twig，…我特别想知道的是下一个:哪一个解析更快，例如Smarty缓存比使用纯PHP更快?哪个模板引擎是最快的?我要重写一个简单的程序，速度是第一位的。
"视情况而定"是你所有问题的答案。
什么是"更快"?执行时间?开发时间?维护吗?内存开销?它们的混合?模板引擎通常会牺牲一些性能(速度、内存)来换取更好的开发和维护。
如果你谈论的是纯动态模板(意思是:对每个请求评估模板)，PHP将超过任何模板引擎。这是一个显而易见的问题，真的。如果要考虑缓存，Smarty这样的模板引擎可能会有所帮助。不过，缓存并不是无法在纯PHP中实现的。有了Smarty，这一切都已经为你完成了(而且比你想象的要复杂得多)。
如果你正在使用一个框架，比如Symfony，那么使用Twig可能是明智的，因为Twig和Symfony是紧密集成的。当然，您可以使用Smarty或纯PHP。这里的问题是:它可行吗?
当从数据库或远程api等数据源构建站点时，缓存是有意义的。这里真正节省(在某种意义上说是减少)的是数据库调用、密集的计算等。检查您是否有任何时间密集的功能运行来构建您的网站。如果是，使用缓存(如果可以的话)。了解开发/维护/便利/性能的权衡，我会(总是)推荐使用模板引擎。作为一名Smarty开发者，我当然会建议使用Smarty。除非你正在使用Symfony，否则你最好使用Twig。或者使用其他模板引擎的框架。
请忽略Smarty vs. Twig这样的帖子，因为他们只比较了一个非常有限的引擎视图。不要相信你自己没有伪造的基准。
总的来说，Smarty 3.1比Twig快一点。Twig在运行时(模板执行的时间)做了很多Smarty在编译时(模板准备执行的时间)做的事情。Twig在这里并没有浪费速度。Twig需要在运行时按照设计做一些事情。他们牺牲了一点性能换取了一点"方便"(例如，使用相同的符号访问数组和对象)。
让我们把与这个主题相关的比喻分开来看:
1。不要把逻辑放到演示文稿中——不要把"代码"放进你的HTML
说这句话然后告诉你使用模板的人是矛盾的:
- PHP是一种解释的语言-它在执行时变成C代码。
- 模板'语法'被解释为PHP
他们必须停止欺骗自己。他们的"模板语法">是一种构建在另一种编程语言之上的编程语言，而另一种编程语言又构建在另一种语言之上——这是低效的，冗余的，而且奇怪的。
此外，我不明白为什么每个模板引擎所依赖的变量的存在不被认为是逻辑的——它们的存在、内容和实现依赖于逻辑后端。
那么那些使用if/else语句和for循环的模板系统呢?这就是逻辑的本质——大多数编程语言使用的概念。它们需要变量数据，这些数据只能通过某种形式的计算生成或存在。如果不混合表示和逻辑，就不能提供动态内容。这是不可能的。
2.1它更安全…
所以，你不相信你的HTML家伙?
:你认为你的HTML/CSS的家伙是愚蠢的，会不小心打印数据库密码
如果是这样的话，我要告诉你——如果敏感数据可以从程序内的任何地方访问/修改，那么你的环境已经不安全了。
:您认为您的HTML人员将打印随机的服务器常量-允许他作为个人使用服务器逻辑是危险的
我明白了——他要么愚蠢，要么讨厌他的工作，想被解雇，因此会做一些愚蠢的事情，比如打印会话变量。好吧，但是我要说…
…为什么这些东西不经同行评审？ 即使他没有访问直接的服务器逻辑，而是一个花哨的模板系统，他仍然可以同样地传播他的愚蠢/仇恨，仅仅因为他对输出有最终决定权。或者，他甚至可能与另一个程序员(如果有的话)勾结在一起，仍然访问服务器常量和co.
2.2.1好的模板引擎会自动清理输出，或者允许模板人员自己清理——他更清楚什么时候应该清理数据
你假。
你不知道什么时候输出应该被清理?你自己做不到吗?
即便如此，也许你只是一个代码猴子，而HTML家伙是一个网络安全的HTML注入专家，而应该是一个清理输出的人。在这种情况下，让他访问PHP也允许他使用htmlspecialchars()之类的东西，而不是模板给他的任何东西来做同样的事情。
,
2.2…我可以用
控制正在处理的数据
想想类、函数等等——你把数据扔进去，它们处理它，然后你得到一个结果。通常，他们不处理外部数据，除非交给他们(否则是不明确的、危险的和不好的做法——除了一些常量)。通过这些相同的方法，您可以准确地将您需要的内容以高效，清晰和无限的庄园传递给您的输出。
,
总而言之，你认为你的模板引擎比纯代码更安全的原因似乎是你缺乏几个通用的安全性:
- 您(或任何人)不同行评审内容-您允许个人输出内容。
- 您没有实现正确或安全的编程实践，并且似乎没有意识到您可以控制从A传递的内容。B到。
3。PHP语法太难/很难教style people
事实上，它并不比模板系统(如Smarty)创建的伪语法更复杂，所以如果这是一个问题，那么动态内容不适合你。
以下是PHP的"简短语法"-它太难了吗?
<div class='username'><?= $username ?></div>
4。开发我自己的解决方案太费事了
虽然我认为它不是，你可以自由选择任何你想要的!选择最适合你需要的东西。它们通常是免费的，不难集成，并且自带大量的功能。
我的印象是，大多数人选择模板只是因为它在文件中看起来更"整洁"——他们喜欢认为TPL文件是他们创建的一些特殊的东西，他们喜欢语法的方式;就像通过某种魔法一样，这个变量被小小的@或#符号"调用"，并从您的逻辑跳到输出中。
这似乎是一个诡计-美丽的女巫(AKA模板引擎)吸引你在她的美丽。虽然她很吸引人的眼睛，但她真的是一个吸血的恶魔，抽取你的灵魂(服务器资源)，以换取别人看不到的养眼的东西(你的用户宁愿有一个更快的网站和更多的功能，你节省了电力/服务器租金)
<title>{{@title}}</title>
Vs
<title><?= $title ?></title>
我承认，我能想到的模板比PHP有优势的地方只有一个——可移植性。Appartisan的回答解决了这个问题。即便如此，用{{@var}}替换<?= $var ?>也并不难——这就是模板式系统的工作。
简单地说，我认为唯一的优点是可移植性。可以将模板引擎中的模板或视图重用到其他后端应用程序中。假设您要将应用程序从PHP迁移到Java，则不需要重构模板。
否则，您将增加复杂性，增加其他执行层(更多时间)，增加维护应用程序的需求(您需要了解模板引擎的人员)，等等。PHP本身是最好的，功能更强大的模板引擎，可能是最快的，你也可以做缓存，从后端应用程序控制缓存的优势，而不是从视图。
我将再次讨论这个问题，因为事情已经发生了重大变化，而且前面的答案缺少了一些证据。
没有深入了解为什么框架使用模板引擎而不是PHP，大多数框架都是这样做的。由于某种原因，人们一直在努力用另一个抽象层来"修复"PHP。总是声称简单而不损失多功能性和性能。
无论如何，使用PHP仍然是最快和最通用的模板方式。PHP最早的版本看起来很像一种模板语言。但是让我们来看看PHP的进步，并将它们与after层并列。Twig和其他一些人声称缓存一些东西，这在早期版本的PHP中一直是一个插件。缓存现在是PHP5.5+ (Opcache)的默认部分，因此使用PHP作为模板语言将提供更多的性能增强。
Twig和其他人声称为设计师提供了简单的语法。在比较模板引擎的语法时，您会发现逻辑是相似的，使用像Twig这样的模板系统的唯一好处是在设计器和底层系统代码之间建立了另一层安全隔离。
两个非常流行的CMS Wordpress和Drupal使用PHP作为他们的模板引擎。因此，在设计网站时使用模板引擎来保护和简化PHP使用的老论点在今天的网络中并不真正有效。虽然Drupal 8正在转向Twig，但主要是因为Twig是Symfony框架的一部分(回到框架为什么使用模板引擎)。另一方面，Wordpress仍在使用PHP。随着Wordpress的飞速发展，网页设计师使用PHP来帮助实现这一目标。drupal社区也因使用Twig和Symfony的决定而部分分裂。
因此，就性能而言，使用PHP似乎是更好的选择，同时也是主题和设计人员的首选。至少所有的证据都指向这个结论。
话虽如此，这是我毫无根据的观点。我认为，在今天的web中，使用PHP以外的任何东西作为模板引擎，都掩盖了底层框架或web应用程序架构的一些固有弱点。这个弱点是它的复杂性，不能在设计师或主题层面上轻易解释。如果你正在编写一个轻量级的应用程序，它必须很小。通过使用PHP来保持它的小型和最佳性能，并将其他引擎留给"企业"级组和项目
我对逻辑和数据显示必须尽可能分开的论点有一个问题。我发现数据验证和显示实际上需要大量的表单逻辑。关于数据类型、数字范围、不同数据之间的关系等信息需要大量的代码。真正的问题是，我们应该在服务器端使用模板语言，还是在客户端使用Javascript。通过使用Ajax和客户端代码进行数据显示和验证，我最终只需要很少的模板代码。模板引擎最大的问题是引入了新的代码规则和语法。我看到PHP、Jquery、Ajax和模板引擎的未来正在失去吸引力。