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有什么作用
参考用，可以套用模式易于创作;