是否值得爲服務器端使用預編譯jade + handlebars？

我將玉與句柄混合在一起，這樣我就不必編寫HTML，並且可以爲數據相關的東西提供很好的語法。是否值得爲服務器端使用預編譯jade + handlebars？

例如，這可能是頭模板，header.handlebars.jade

html 
    {{#with user}} 
    {{if user.username}} 
    header Welcome back, {{username}} 
    {{/if}} 
    {{/with}}

我想知道如果我當我使用它的node.js服務器端應預編譯該模板玉，然後把手？如果我不這樣做，我基本上是在每個請求上編譯這個模板2次（第一個玉，然後把手）。

我不完全確定這是否起到任何作用，但似乎jade.compile和Handlebars.compile是同步函數，這意味着只要編譯發生，它們就會阻止其他請求。

來源

2013-03-13 ragulka

翡翠在某些方面被認爲很慢，但很難回答這種問題。我建議你爲_你的具體情況構建一個基準並檢查結果。（例如，每個服務器負載的併發連接數）。一般來說，如果可以的話，總是值得編譯你的模板。 – 2013-03-13 15:15:54

是的，預編譯模板可能是個好主意。其原因是，使用模板通常包括兩個步驟：

解析
生成從所述數據串，並將解析的模板

解析是昂貴的操作。它基本上包含一個識別令牌（特殊詞）和構建樹結構。例如：

{{#with author}} 
    <h2>By {{firstName}} {{lastName}}</h2> 
{{/with}}

此塊可以被認爲是樹與父母with聲明和幾個孩子"<h2>By "，firstname，lastName和"</h2>"。

當您預編譯模板時，您正在生成的代碼是解析並生成該樹結構的代碼，因此每次使用該代碼時都不需要解析並生成樹。您正在節省很多CPU週期。

邏輯與您是否應該在服務器啓動時同步讀取某些文件或每次讀取它們時一樣。如果您在開始時閱讀模板文件，則可以減少IO操作，但您使用更多內存來存儲這些模板的內容。解析也是一樣。

我們中的很多人做的是確定哪些資產將被大量使用（模板通常在這個類別中），將它們緩存在內存中，並讓剩餘資源按需讀取。這意味着您不能只更改模板並更新您的網站。您需要對您的站點進行版本控制，並且爲了進行更新，您必須殺死Node進程並重新啓動它。這對您的網站來說是否是一個好主意取決於您如何組織您的部署。

就結合Jade和Handlebars而言，它看起來不是一個好主意，因爲渲染兩個不同模板的代價較高，而且只能預編譯其中的一個。您無法預編譯它們，因爲一個模板取決於另一個的結果。在你的情況下，Jade模板的「源代碼」取決於應用Handlebars模板的結果。

來源

2013-03-13 15:37:38 juandopazo

感謝您的詳盡解答。實際上，我理解預編譯模板背後的基本原理和一般理念（我爲客戶端做的）。我只是想，如果我應該預先編譯服務器端（它看起來不像express + jade是默認預編譯的）。至於混合玉和車把 - 我的Jade模板輸出實際上並不依賴於把手。我總是首先解析Jade，然後解析Handlebars。我只使用Jade，因爲我不想寫簡單的HTML。但是，您關於在應用程序啓動時加載模板並緩存它們的想法很有趣。 – ragulka 2013-03-13 15:46:27

是的，我應該解釋預編譯和編譯之間的區別。 Handlebars中的預編譯實際上與編譯相同，但將JavaScript源代碼作爲字符串而非可執行代碼返回。即，'eval（precompile（tpl））<=> compile（tpl）'。我稍後會更新我的答案。 – juandopazo 2013-03-13 17:04:20

是否值得爲服務器端使用預編譯jade + handlebars？

回答

相關問題