純PHP/HTML視圖VS模板引擎的意見

Question

我想知道哪種方法更快，使用純PHP在HTML文件或使用模板引擎，如Smarty的，嫩枝，... 我想特別知道下一步：哪個解析速度更快，例如Smarty緩存比使用純PHP更快嗎？ 哪個模板引擎最快？我即將重寫簡單的應用程序，其中速度是第一位的。

Answer 1

「取決於」是所有問題的答案。

什麼是「更快」？執行時間處理時間？開發時間？保養？內存開銷？他們的混合物？模板引擎通常在某些性能（速度，內存）方面進行交易，以獲得更好的開發和維護。

如果你談論的是純粹的動態模板（意思是：模板在每次請求計算），PHP將逃脫任何模板引擎。這真是一個拙劣的人。如果考慮到緩存，像Smarty這樣的模板引擎可能會有所幫助。儘管如此，緩存是你無法在普通PHP中實現的東西。有了Smarty，它只是爲你完成的（並且要比你想象的要複雜得多）。

如果您正在使用的框架，比如Symfony的，它可能是明智的使用嫩枝，嫩枝作爲和Symfony的緊密集成。當然你可以使用Smarty或普通的PHP。這裏的問題是：是否可行？

當像數據庫或遠程API那樣從數據源構建網站時，緩存很有意義。你真正保存的東西（從某種意義上來說）是數據庫調用，密集計算等等。檢查是否有任何時間密集型功能運行來構建你的站點。如果是這樣，請使用緩存（如果可以的話）。

瞭解開發/維護/舒適/性能權衡，我會（總是）建議使用模板引擎。作爲一名Smarty開發人員，我當然會建議使用Smarty。除非你使用Symfony，否則你可能會更適合使用Twig。或者一些其他框架具有其他模板引擎。

請忽略帖子像Smarty vs. Twig，因爲它們只比較引擎非常有限的看法。不要相信你沒有僞裝的基準™。

但是，一般來說，Smarty 3.1比Twig快一點。 Twig在運行時（正在執行模板的時候）正在做很多Smarty在編譯時（即模板準備執行時）所做的工作。 Twig在這裏並不是真的在放慢速度。 Twig需要在運行時通過設計來做某些事情。他們用一些「方便」（比如用相同的符號訪問數組和對象）交易了一點性能。

Answer 2

由於情況發生了很大的變化，我會再次採取這種做法，並且前面的答案中缺少一些證據。

沒有深入瞭解爲什麼框架使用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是在性能方面是更好的選擇，但也爲主題製作者和設計師前進的偏好。至少所有的證據都能得出這個結論。

這是說這裏是我毫無根據的意見。我認爲在今天的網絡中使用除PHP以外的任何其他模板引擎都會覆蓋底層框架或Web應用程序體系結構中的一些固有弱點。這個缺點是它的complexities and complications，無法在設計師或美國人的層面上輕易解釋。

如果您正在編寫一個必須很小的輕量級應用程序。保持它小，並通過使用PHP的最佳性能，並保留其他引擎「企業」級組和項目

Answer 3

簡單而純粹的意見，我認爲唯一的優勢就是便攜性。您可以將模板或視圖從模板引擎重新用於其他後端應用程序。假設您將應用程序從PHP移動到Java，則不需要重構模板。

否則，你就增加了複雜性，增加執行（更多的時間）的其它層，更高的要求，以維護應用程序（你需要知道的模板引擎的人），等等。 PHP本身就是你將要獲得的最好，功能更強大的模板引擎，可能是最快的，並且你也可以進行緩存，同時從後端應用程序控制緩存，而不是從視圖控制緩存。

Answer 4

讓我們撕裂與本主題分開比喻：

保持邏輯結束演示了 - 不要把「代碼」到你的HTML

任何人誰說，這然後告訴你去與模板是​​矛盾的：

• PHP是解釋語言 - 它在執行時變成C代碼。
  
• 模板 '語法' 是解釋到PHP

他們必須停止騙自己。他們的'模板語法'是一種編程語言，它構建在另一個之上，而語言又構建於頂部，但是另一個語言 - 這是效率低下，冗餘和奇怪。

此外，我看不到變量這曾經是依賴於不被視爲邏輯在每個模板引擎的存在如何 - 他們的存在，內容和實施取決於邏輯後端。

與如果/其他報表和爲循環的模板系統的什麼，？這就是邏輯的本質 - 大多數語言所使用的編程的概念。它們需要變量只能通過某種計算形式生成或存在的數據。

如果不將邏輯與演示混合在一起，則無法提供動態內容。不可能。

---

2.1它的安全...

所以，你不要信任你的HTML的傢伙？

案例：你認爲你的HTML/CSS的人是愚蠢的，一不小心就會打印數據庫密碼

如果這是你的話，我已經得到了消息 - 你的環境已經不是安全的，如果敏感數據從程序中的任何地方訪問/修改。

案例：你認爲你的HTML的人將打印服務器隨機常數 - 這是危險的，讓他，作爲一個個體，與服務器的邏輯工作

我看到 - 他要麼愚蠢，還是恨他的工作，想要被解僱，因此會像打印會話變量一樣愚蠢。很好，但我會說...

...爲什麼這是這東西不是同行評審？即使他沒有使用直接的服務器邏輯，而是使用了一個特別的模板系統，但他仍然可以平等地傳播他的愚蠢/仇恨，僅僅是因爲他對輸出有最終的說法。或者，他甚至可能與另一位程序員（如果有的話）進行綁定，並仍然訪問服務器常量和合作夥伴。

-

2.2.1良好的模板引擎自動消毒輸出，或允許模板 - 蓋伊做自己 - 他知道更好，當數據應被消毒

你這笨蛋。

你不知道什麼時候應該對輸出進行消毒？你自己不能這樣做..？即使如此，也許你只是代碼猴，而HTML傢伙是一個網絡安全的HTML注入專家，並且他應該是一個消毒輸出。在這種情況下，讓他訪問PHP也允許他使用htmlspecialchars()之類的東西，而不是模板給他做同樣的事情。

關於自動轉義，假設您安全地傳遞內容，您可以在代碼中實現這樣一個簡單的功能。

-

2.2 ...我可以控制哪些數據被用

合作想想類，函數，等等 - 你扔在數據，他們工作它，那麼你會得到一個結果。通常他們不會處理外部數據，除非交給他們（否則做法不清楚，危險和不好的做法 - 不考慮一些常數）。通過這些相同的方法，您可以在高效，清晰和無限的莊園中精確傳遞您的輸出內容。

-

所有這一切說，好像你認爲你的模板引擎是比任何明碼更安全的原因是因爲你缺乏一般安全幾個方面：

• 您（或誰）不同行評審內容 - 您允許個人輸出內容。
• 您沒有正確執行或安全的編程實踐，而且似乎沒有意識到，你可以控制什麼是從點一個到乙傳承下去。

---

PHP語法太硬/難教的人們

事實是，它沒有複雜得多，用模板等系統創建的僞語法作爲Smarty，所​​以如果這是一個問題，那麼動態內容不適合你。

以下是PHP的簡短語法 - 它太難了嗎？

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

---

4.這是太多的工作，開發自己的解決方案

雖然我要說這不是，你可以自由選擇任何你想！選擇最適合您的需求。它們通常都是免費的，不難整合，並且提供大量功能。

---

---

我的印象是，大多數人選擇的模板，只是因爲它看起來在文件中「整潔」 - 他們愛思考的TPL文件爲他們創造一些特別的東西，他們喜歡語法的樣子;就像通過一些魔術一樣，這個變量被小的@或#符號'調用'，並從您的邏輯跳到輸出中。

這似乎是一個把戲 - 美麗的女妖（又名模板引擎）吸引你與她的美麗。雖然她很吸引人的眼球，她真的吸血惡魔和提取你的靈魂（服務器資源）換取眼睛糖果沒有人看到（您的用戶寧願有一個更快的網站和更多功能資助便攜性 - 在$$$你省電/服務器租用）

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

---

---

我會承認，只有一種情況下，我能想到的在模板中有超過PHP任何理由上其他應用。 appartisan的回答解決了這個問題。即便如此，用{{@var}} - 替換<?= $var ?>並不難，這是模板化系統的一項工作。

Answer 5

我有一個論點，即邏輯和數據顯示必須儘可能分離。我發現數據驗證和顯示實際上需要很多表單上的邏輯。關於數據類型，數字範圍，不同數據之間的關係需要大量的代碼。真正的問題是我們應該在服務器端使用模板語言還是在客戶端使用Javascript。通過使用Ajax和客戶端代碼進行數據顯示和驗證，我最終得到的模板代碼非常少。模板引擎最大的問題是新代碼規則和語法的引入。我看到PHP，Jquery和Ajax以及模板引擎失去了吸引力。