伴随项目的日渐成熟，作为产品开发亦是对ApiCloud日渐熟悉，回过头看当时界面渲染模块选择时，因为doT的属于极为轻量（压缩之后4K）,再加上doT是官方自主配套渲染模块，其稳定性比较好，所以当时选择了doT模板为工程界面渲染模块。 在实际使用中，其稳定性无可厚非，但是其在书写逻辑上，总觉得还有所欠妥。下面列举个人实际开发中觉得不舒服的地方，简单论述下：

doT模板需要给元素重新赋值时，需要对该元素绑定id，通过id去寻找该元素再去赋值；
列表渲染中，需要提前判断，当前加载的页数，用来判别是直接渲染还是添加渲染，另外需要手动给渲染到界面上的数组绑定index（该模板会默认每次的渲染都是从0开始）；
doT不存在局部渲染的概念，全局渲染总能引起‘闪动’，虽然可以通过id去寻找元素，模拟局部渲染，但是如果局部渲染元素较多的话，代码量就增加了；
doT的书写格式，比较容易出错，少些一个“}”或者多写一个，也不指定哪里出错了，代码少的话，还好，多的话，排查起来就比较费时间；

doT模板在渲染时，一次只能插入一个对象，有几个不同对象建立几个对应的template。
……
如果是简单界面的渲染，doT绝对首选，但是如果是复杂的界面，尤其是列表加载，doT渲染着实让开发者觉得有点不舒服。作为曾经用过Vue开发的我来说，也是不曾一次的和同事探讨过，为什么不能用Vue？

带着自己的疑问，在不断的自我学习中，一次看到官方视频里有推荐开发者可以使用vue.js进行ApicCloud工程开发，当即用vue.js做了一个简单的demo，其流畅性和渲染速度跟doT相比，只强不差。下面对应上述doT暴露的比较明显的问题，做下简单的比较论述：

双向数据绑定：vue.js会自动响应数据的变化情况，并且根据用户在代码中预先写好的绑定关系，对所有绑定在一起的数据和视图内容都进行修改。这也就是vue.js最大的优点，通过MVVM思想实现数据的双向绑定，让开发者不用再操作dom对象，有更多的时间去思考业务逻辑；
视图,数据,结构分离：使数据的更改更为简单,不需要进行逻辑代码的修改,只需要操作数据就能完成相关操作。比如，列表加载数组时只需向该数组push即可，列表会随数组长度变化而变化，并且index为自增；
vue.js 除了数据双向绑定中直接的局部渲染操作，还提供了其他API 对对象、数组等进行局部渲染；
vue.js书写规范，可阅读性很高；
可以同时插入多个对象（数组）一起渲染，提高了渲染效率，也大大减少了界面逻辑的书写和重复逻辑的判断。
针对渲染效率，做了一个vue.js和doT渲染相同表格的比较：

只渲染一次：
vue: 1.94189453125ms
dot: 4.362060546875ms
连续渲染三次：

从运行时间来看，列表数据渲染的多少对doT影响还是挺大的。

另外，vue发展至今其所包含的api几乎都能用（目前的业务逻辑我还没发现不能用的），与主流的web框架相比，vue.js压缩之后的包也仅仅八九十KB，属于轻量级，但是其api与doT相比也算海量了，就像一个判断语句，v-if 和 v-show 都可以当做条件判断，两者区别仅仅是v-show可以用来判断频率（切换频率）比较高的，渲染效果更好。

总而言之，vue.js的引入，从开发角度可以少写部分代码，以及不需要判断某些逻辑，提高开发效率。

vue.js使用注意事项：

在style中加入 [v-cloak] { display: none; }
在body中需要vue渲染的div包裹进一个div内，该div加上v-cloak，避免渲染慢。
详细使用可见： 本部门共同维护工程FunTemplateApp，其中一页分别加载了含有相同的二十个对象的数组（数据为静态数据，图片为网络资源），作为两个模块的渲染比较。对应的APP界面位置在第三个界面，Vue.js渲染列表和doT渲染列表；对应的代码界面为html/vuedot/vuehtml.html 和html/vuedot/dothtml.html，demo运行，二维码下载可见。