weex 小结
先说说优点把：
跟vue一样的开发方式，在页面当中template style script分别代表的是html css js跟传统的web开发模式是一样的，所以说在开发体验上会十分的舒服，而且代码管理上也会相对来说比较好管理。可以很直观的理解到一个.we文件就一个module，不管它是主页面还是component都能理解成模块。
性能上从demo的使用上来说week已经在优化方面做了很多很多的功课，也就是说自己要做的优化会少很多，这个时候免不了对比RN，RN其实很多时候跑的快不快性能好不好还是要看下开发者的代码。可以参考分析对比—https://github.com/xitu/gold-miner/blob/master/TODO/a-fairer-vue-of-react-comparing-react-to-vue-for-dynamic-tabular-data-part-2.md
体验上来说，因为性能跟上了，所以基本上从官方给出的Demo中所有的app中可能碰到的基本操作的流畅度都是能保持到60FPS的，这点很重要，特别是滚动列表这种最能衡量性能的东西，weex还是表现很好的。
下面说说目前的不足的吧：
社区：可能跟这个时间weex并没有正式开源只是内测有关系，官方弄了一个weex的比赛，然后结果是普通的开发者如果对于ios或者android不是很熟悉的话，基本上大部分的时间不在开发上而是卡在了配置开发环境跟解决开发过程中遇到的坑上。这个就有点尴尬了官方的文档也有很多很多（这里强调了一下）需要改进的地方，自己也在群里跟github上提了一些修改（连我这个渣渣都能提好多问题说明真的是很多文档要改进的地方）。确切的说是很难在通过只看文档的方式去完整的开发出一个小的demo，而且文档很缺发工程化的介绍跟例子，基本上都是单页面的东西。
配套的工具：vue的周边环境其实并不是很大，weex作为vue的混血孩子，自然更是缺乏这些东西，IDE方面有一个atom上的语法插件，weex-loader（weex官方推荐是webpack去做构建打包）也并不是很完善（貌似要依赖一些官方都觉得过渡用的自用插件），所以前期想自己创建工程或者嵌入工程去构建的话还是有些困难。表示在没有IOS的同学帮助下将weex嵌入到一个新工程几乎是不可能的。官方现在也是推荐在他们的playground里面写代码。
对于原生组件的支持度不太够把，可能过个半年会很好很多，只是现在看来，还是不太够，而且很关键的对于动画，对于手势的支持也是不够的，虽然RN的手势和动画很坑爹，但是至少支持度还是很全，（facebook有一个自己的现有的成熟的动画库移植到RN上了）。
第三方的组件的开发，因为没有开源，这方面可以理解为零。而且对于第三方的支持weex还很初步，这意味着web中的一些开发工具或者像字体之类的东西是不能直接移植到weex当中的，但是underscore.js这种javascript方法库还是ok的。
总结：
等=等官方文档完善+等官方的best practise+等周边社区繁荣
前景目前来说还是很乐观
目前来可以尝试在IOS同学的帮助和监管下尝试融合到现有项目中一点点，然后对比weex跟H5看weex能具体带来哪方面的优势，优势多大，又会带来什么样的坑，坑大不大。
RN从开源到现在已经快一年半了，从周边组件到社区到资源感觉已经是可以说是整个前端圈里最活跃的技术了，这个跟官方的演讲，官方的持续跟进文档更新，周边工具的更新脱不了关系，所以weex想要成熟，不只是代码的成熟还得靠周边文档跟社区跟上。
附上自己测试写的一个小demo截图
