纯PHP / HTML视图VS模板引擎视图

时间:2012-02-20 15:02:18

标签: html templates smarty twig

我想知道哪种方法更快,在HTML文件中使用纯PHP或使用Smarty,Twig等模板引擎...... 我特别想知道的是:解析得更快,Smarty缓存比使用纯PHP更快吗? 哪个模板引擎最快?我即将重写速度最快的简单应用程序。

5 个答案:

答案 0 :(得分:21)

“取决于”是您所有问题的答案。

什么是“更快”?执行时间处理时间?开发时间?保养?内存开销?它们的混合物?模板引擎通常以某种性能(速度,内存)进行交易,以便更好地进行开发和维护。

如果您正在谈论纯动态模板(意思是:在每个请求中评估模板),PHP将超过任何模板引擎。真的,这是一个nobrainer。如果您考虑缓存,像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需要在运行时通过设计来做某些事情。他们为了一些“Convenienve”交换了一些性能(例如,访问具有相同表示法的数组和对象)。

答案 1 :(得分:9)

让我们撕掉与此主题相关的转义:

  

1。将逻辑排除在演示文稿之外 - 请勿将代码放入'进入你的HTML

任何说出这个然后告诉你使用模板的人都是矛盾的:

  • PHP是一种解释语言 - 它在执行时成为C代码。
  • 模板语法'是解释到PHP

他们必须停止对自己撒谎。他们的模板语法&#39; 一种基于另一种编程语言的编程语言,而该编程语言又构建在另一种语言之上 - 这种语言效率低,冗余,并且怪异< / em>的

此外,我没有看到变量每个模板引擎的存在依赖于什么都不是逻辑 - 它们的存在,内容和实现依赖于逻辑后端。

那些带有 if / else 语句和 for 循环的模板系统是什么?这就是逻辑的本质 - 大多数编程语言所使用的概念。它们需要变量数据,这些数据只能通过某种形式的计算生成或存在。

如果不将演示与逻辑混合,则无法提供动态内容。这是不可能的。

  

2.1 它更安全......

那么,你是不是信任你的HTML家伙?

案例:您认为您的HTML / CSS家伙很愚蠢,会不小心打印数据库密码

如果是这样,我已经收到了消息 - 如果可以从程序中的任何位置访问/修改敏感数据,那么您的环境已经不安全。

案例:您认为您的HTML人员会打印随机服务器常量 - 允许他作为个人使用服务器逻辑是危险的

我明白了 - 他要么是愚蠢的,要是讨厌他的工作而想要被解雇,因此会像打印会话变量一样愚蠢。很好,但我要说......

...为什么这些东西不是同行评审?即使他无法获得直接的服务器逻辑,而是一个花哨的模板系统,他仍然可以平等地分散他的愚蠢/仇恨,仅仅是因为他对输出有最终决定权。或者,他甚至可以与另一个程序员(如果有的话)合作,并且仍然访问服务器常量和co。

-

  

2.2.1 好的模板引擎会自动清理输出,或允许模板人自己做 - 他知道数据应该消毒吗

你是假的。

您不知道什么时候应该对输出进行消毒?你自己也做不到......?

即便如此,也许你只是代码猴而HTML人是网络安全HTML注入专家,应该是一个消毒输出。在这种情况下,让他访问PHP也允许他使用htmlspecialchars()之类的内容,而不是模板给他做同样的事情。

关于自动转义,只要你安全传递内容,就可以在你正在执行的代码中实现这样一个简单的功能。

-

  

2.2 ...我可以控制正在使用的数据

考虑类,函数等 - 您将数据输入,它们使用它,然后您得到一个结果。通常他们不处理外部数据,除非交给他们(否则不清楚,危险和不好的做法 - 除了一些常数)。通过这些相同的方法,您可以在高效,清晰和无限的庄园中准确传递您所需的输出。

-

所有这一切,似乎你认为你的模板引擎比普通代码更安全的原因是因为你缺乏一般安全的几个领域

  • 您(或其他任何人)不会查看评论内容 - 您允许个人输出内容。
  • 您没有实施正确或安全的编程习惯,似乎没有意识到您可以控制从 A 的传递内容乙即可。
  

3。 PHP语法太难/难以教人风格

事实上它并不比Smarty等模板系统创建的伪语法复杂,所以如果这是一个问题,那么动态内容对你来说就不是了。

以下是PHP&#39;短语法&#39; - 太难了吗?

<div class='username'><?= $username ?></div>

  

4. 开发自己的解决方案需要做太多工作

虽然我认为不是,但你可以自由选择任何你想要的东西!选择最适合您需求的产品。它们通常是免费的,不易于集成,并且具有开箱即用的大量功能。

我的印象是,大多数人选择模板只是因为它看起来更整洁。在文件中 - 他们喜欢认为TPL文件是他们创建的一些特殊内容,他们喜欢语法的外观;好像通过一些魔法,变量被称为&#39;通过小@#符号,从您的逻辑跳转到输出。

这似乎是一招 - 美丽的女巫( AKA模板引擎)吸引了她的美丽。虽然她吸引眼球,但她真的吸血鬼并提取你的灵魂(服务器资源)以换取眼睛糖果别人看到(您的用户更愿意拥有一个更快的网站更多功能由$$$资助您节省电力/服务器租用)

<title>{{@title}}</title>
Vs
<title><?= $title ?></title>

我承认,只有一个案例我可以想到哪些模板与PHP有任何关系 - 可移植到其他应用程序。 appartisan的答案解决了这个问题。即便如此,用<?= $var ?> - 取代{{@var}} 作为模板系统的工作也不难取而代之。

答案 2 :(得分:5)

简单而纯粹的意见,我认为唯一的优势是可移植性。您可以将模板引擎中的模板或视图重用到其他后端应用程序中。假设您正在将应用程序从PHP迁移到Java,则无需重构模板。

否则,您将增加复杂性,添加其他执行层(更多时间),维护应用程序的更多要求(您需要知道该模板引擎的人员),等等。 PHP本身它是你将获得的最好和更有特色的模板引擎,可能是最快的,你也可以进行缓存,具有从后端应用程序控制缓存的优势,而不是从视图。

答案 3 :(得分:4)

我会再次接受这一点,因为事情已经发生了重大变化,并且早期答案中缺少一些证据。

没有深入了解为什么框架使用模板引擎而不是PHP。出于某种原因,人们不断努力用另一个抽象层“修复”PHP。始终声称简单而不失多功能性或性能。

无论如何,使用PHP仍然是最快速,最通用的模板方式。 PHP中的earliest incarnations看起来很像模板语言。但是让我们看看PHP中的进步并将它们与the after layers并排放置。

Twig和其他一些人声称在早期版本的PHP中缓存了一些东西。缓存现在是default part of PHP5.5+(Opcache),因此使用PHP作为模板语言将提供更多性能增强。

Twig和其他人声称设计师使用简单的语法。在比较syntax of a template engine时,您将看到逻辑类似于使用模板系统的唯一好处,如Twig是设计器和底层系统代码之间的另一层安全隔离。

两个非常流行的CMS Wordpress和Drupal使用PHP作为模板引擎。因此,在设计网站时使用模板引擎来保护和简化PHP使用的旧观点在今天的网络中并不真正有效。虽然Drupal 8正在转向Twig,但主要是因为twig是Symfony Framework的一部分(回到为什么框架使用模板引擎)。另一方面,Wordpress仍在使用PHP。随着Wordpress与网页设计师之间的跨越式发展,使用PHP来帮助实现这一目标。 Drupals社区也因使用Twig和Symfony的决定而分裂。

因此,在性能方面使用PHP似乎是更好的选择,而且对于前人和设计师的偏好也是如此。至少所有证据都可以得出这个结论。

这里说的是我毫无根据的意见。我认为在今天的Web中使用除PHP之外的任何东西作为模板引擎,都涵盖了底层框架或Web应用程序架构中的一些固有缺陷。这个弱点是它的complexities and complications无法在设计师或者以前的水平上轻易解释。

如果您正在编写一个必须很小的轻量级应用程序。使用PHP将其保持小巧并以最佳方式执行,并将其他引擎保留为“企业”级别组和项目

答案 4 :(得分:0)

我对逻辑和数据显示必须尽可能相互分离的论点存在疑问。我发现数据验证和显示实际上需要在表单上有很多逻辑。有关数据类型,数量范围,不同数据之间关系的信息需要大量代码。真正的问题是我们应该在服务器端使用模板语言还是在客户端使用Javascript。通过使用Ajax和客户端代码进行数据显示和验证,我最终得到的模板代码非常少。模板引擎的最大问题是新代码规则和语法的引入。我看到了PHP,Jquery和Ajax的未来以及模板引擎失去了它的吸引力。