1. arttemplate給子模板指定數據 這個問題你後來解決了嗎
由於您沒有提出實質的問題，所以無法給予您更詳細的回復，請您詳細的描述出現的問題，這樣才可以根據您的機型及出現的問題，提出針對性的解決方案。
希望以上信息可以幫到您！
2. arttemplate怎麼提取公共部分
不知道你說的完整是什麼意思。不需要完整的頁面 html 結構，只需要 html 片段就行；
目前 artTemplate 的引入只有 {{include './footer_tpl'}} 這一種引入方式；
這個就看自己怎麼拆分了，把公共的部分拆到另外模板，再用 include 引入就行；
渲染上沒有什麼區別，引入的模板也需要渲染數據，渲染時一同傳入就行。
你就把 include 當成是引入模板代碼拼接到此模板就行，沒什麼深奧的。
3. 有用過artTemplate的嗎，貌似不能支持內置函數，如Math.abs
在函數規模很小的情況下，函數調用的時間開銷可能相當於甚至超過執行函數本身的時間，把它定義為內置函數，可大大減少程序運行時間。
如果內置函數中包含復雜控制語句，內置函數就沒有太大意義了，編譯器會直接編譯為普通函數
4. Arttemplate和react哪個對於頁面的性能最優
react為什麼在github上很火爆，不就是因為他比其他框架優越很多嗎，Facebook團隊看不上別人開發的js引擎，所以自己開發了這一款，並且和angular一起被譽為下一代web技術，豈是
Arttemplate能比的，也許從簡單頁面的速度上來說，Arttemplate可能給人的感覺是速度切換的快，但是在中端和高端web中，react的速度優勢就很明顯了，你想想Facebook的用戶有多少，能支持這么多用戶的js引擎，絕對不會差
5. art-template模板繼承我的代碼為什麼繼承不了
類模板可以繼承也可以被繼承。
1.在一個類模板中，一個非依賴型基類是指：無須知道模板實參就可以完全確定類型的
基類。
例如：
template<typename X>
class Base{
public:
int basefield;
typedef int T;
};
class D1:public Base<Base<void> >{//實際上不是模板
public:
void f(){basefield = 3; }
};
template<typename T>
class D2:public Base<double>{
public:
void f() { basefield = 7; }//正常訪問繼承成員
T strange;//T是Base<double>::T,而不是模板參數
};
6. Web前端工程師該如何選擇web前端模板引擎
今天小編要跟大家分享的文章是關於Web前端工程師該如何選擇web前端模板引擎?如果你正在從事web前端工作，如果你也想要了解如何選擇web前端模板引擎的知識，那麼就來和小編一起看一看本文為大家介紹的內容吧~
一、Web模板就在那裡
模板引擎負責組裝數據，以另外一種形式或外觀展現數據。瀏覽器中的頁面是Web模板引擎最終的展現。
無論你是否直接使用模板引擎，Web模板一直都在，不在前端就在後端，它的出現甚至可以追溯到超文本標記語言HTML標准正式確立之前。
二、服務端的模板引擎
我所知道最早的Web模板引擎是PHP，它正式誕生於1997年，工作在伺服器端。讓我們看看PHP官方的intro-whatis：
PHP(「PHP:Hypertext
Preprocessor」，超文本預處理器的縮寫)是一種被廣泛應用的開放源代碼的多用途腳本語言，它可嵌入到HTML中，尤其適合web開發。
PHPer普遍贊同PHP本身就是最天然、原生的PHP模板引擎，因為她本來就是。在PHP的世界裡多次出現過再包裝的模板引擎，著名的有
smarty。
其它伺服器端語言很多都有HTML模板引擎，比如JSP、mustache。
毫無疑問，這些伺服器端模板引擎最終生成的結果是HTML(XML)字元串，處理流程邏輯使用宿主語言本身的語法實現。
它們的共同特徵：HTML只是個字元串,最終結果可能還需要類似Tidy這樣的清潔或修正驗證工具。
這里提出一個問題：二次封裝的smarty有存在的必要麼?
三、瀏覽器端的模板引擎
我所知道最早的前端模板引擎是jCT，它託管於Google
Code，誕生於2008年，宿主語言是javaScript，工作在瀏覽器中。很榮幸，我就是jCT的作者，相關早期博客可以查看achun、githubjCT
備份。
直到今天寫這篇文章，我才發現pure-js這篇文章裡面也提到不少先行者——jemplate最早在2006年就創建了。
今天在OSC搜索JavaScript模板引擎你會得到100+個結果，下邊列舉一些：
·輕量度：tpl.js、T.js
·認知度：arttemplate、mustache.js、doT.js、handlebars.js、pug
·DOM-tree-based：domTemplate、transparency、plates
·VDOM-based：htmltemplate-vdom、virtual-stache、html-patcher
·流行框架：Vue.js、ReactJS、riot
·Real-DOM：PowJS
它們的共同特徵：全都支持插值。
這里還有templating-engines受歡迎度的對比，甚至best-javascript-templating-engines
投票及正反方的理由。
四、如何選擇
我認為存在即合理，每個引擎、框架總有可取之處，至少在你的應用里，在某個時代，所以本文不會評論某個引擎哪一點不好，那樣是不客觀的。現在回答前邊提到的問題：smarty
有存在的必要麼?我的答案是：有。理由很簡單，看給誰用、看大背景。
對於前後端沒有分離的應用，或前端人員對後端語言不夠熟悉，或因崗位職責需要，那麼前端人員掌握一種比較通用的模板語法(語言)是現實的，反之讓PHPer自己去使用
smarty那就太浪費技能了。
下面是通常意義上的引擎選擇建議：
1.前提，選擇的引擎能滿足數據渲染需求，且不和現有依賴沖突，如果你已經非常熟悉某個引擎，那你已經有答案了。
2.是一次性的項目需求么?是的話直接選擇輕量的，學習復雜度最低的。
3.是要做組件開發么?
4.引擎支持預編譯結果，不必每次都實時編譯么?
5.要跨平台么?有官方提供支持的，首選類React-JSX的引擎或純粹的VDOM引擎。
6.選擇學習或維護復雜度最低的，眾所周知，開發者對調試的時間超過寫代碼的時間深惡痛絕。
7.最後才是性能對比，性能對比是一件非常細致的工作，他人的對比結果不一定符合你的場景。
我認為應該弱化語法風格的對比，偏好是沒有可比性的，一些語法甚至有特殊的背景原因。
為什麼最後才是性能對比?
性能的確很重要，但如果性能還沒有影響到你的應用體驗度，那就忽視它。很難真實地模擬應用場景，通常只有通過真實場景來檢驗，目前的測試工具還達不到這種效果。
前述問題有些有固定答案，下面討論餘下的問題：如何考慮組件開發、支持預編譯、復雜度?
五、組件開發
進行組件開發已經不再是選擇模板引擎的問題了，這是生態環境選擇的問題。如果你的應用需要更快地完成，那麼時間點是第一位的，就選擇流行框架，有足夠多的組件讓你使用或參考。如果你的應用有獨立的生態環境，需要技術選型以便長期維護，那繼續看下文。
六、預編譯
預編譯應該具備：
1.編譯結果在目標環境中不再需要編譯過程。
2.編譯結果可調試性，這意味著結果應該包含原生ECMAScript代碼，而不是純粹的數據描述。
大家都知道React-JSX是支持預編譯的，官方的說法是ReactWithoutJSX，即總是build過的。
一些基於字元串處理的引擎也支持預編譯。如果你需要預編譯，建議拋棄編譯結果依然是基於字元串拼接的引擎，那樣還不如不預編譯，那是HTML5未被廣泛支持之前的技術手段。
至少也要有類似React-JSX這樣的編譯結果才具有可調試性。備註：Vue.js支持多種模板引擎，可達到同樣的效果。
原ReactJS代碼，其中用到了WebComponents技術：classHelloMessageextendsReact.Component{
render(){
return
7. 如何實現node渲染用arttemplate與前端也用arttemplate
前端使用原生 js 模板語法版就可以了
8. arttemplate有什麼作用
參考用，可以套用模式易於創作;