泻药，我这几周的工作也是这个… 今天老板转发了这篇文章，感觉自己凉凉了。
首先，从转换的角度来说，应该很多人有写过类似的转换工具，我个人知道的是半年前蘑菇街也已经实现了自己的一套vue单页转换小程序的框架，不过没有开源，有幸和几个蘑菇街的前端有过交流，从整体的技术实现角度上和mpvue有异曲同工之处，但是又柔和了很多他们独特的特殊业务需求在里面，而且因为不支持vue router，所以场景主要集中在活动页的转换上，也可以做到100%的一键转换。mpvue看起来更纯粹，更开源，没有太多的美团业务印记在里头，这很难得。
因为小程序的自定义组件和webview是最近才有的官方支持，所以很多类似的vue2wx的程序的自定义组件转换方法各不相同。如果真的要做到组件复用，还必须要有一套自己的小程序组件和web组件抹平，比如我就是想在web端用组件，我web端已经实现了一个类icon组件，那么这部分mpvue能否提供一套对应web端的类小程序的组件库？
年前美团的同学也来新浪安利过这个技术，不过那个时候还没有开源，所以很多细节还是没有琢磨透。
我自己的那个转换项目，现在才刚刚实现了指令和标签那部分的模版转换，类似mpvue那篇文章中的第一阶段吧，原理上就是通过vue官方的parse生成ast，然后再自己实现一套映射关系的convertAST方法来render出适合小程序的template。在编写转换时，细节的处理比较复杂，主要是要对着vue和小程序的文档一个一个的对，我本身对vue和小程序都不太熟…所以这里开发其实是需要很大的“耐心”才能完成。(而且真的只能是部分支持，毕竟环境不一致导致部分功能真的无法一一对应)
整体来看，mpvue的实现的就非常的漂亮，整体的工程思路，实战项目，文档都有了，包括一些周边，测试用例都很完善。尤其是生命周期同步那一块太秀了…。算是非常的工业级的项目了，对于新项目来说我个人还是比较推荐的。
但是就像其他回答说的一样，现在webview官方已经支持了，两端统一的需求还真的是刚需吗？体验上肯定更好一些，但是我觉得还是要看公司业务是否全都扑在小程序上，这个投入产出比蛮大的，包括后续维护，如果转webview可能成本上更合适，略牺牲体验。
最后，其实转换的需求一直都在，大家写的都是vue转wx，但是其实很多项目都是先有的小程序需求，再有h5的需求，那么支持从wx转到vue的需求我觉的还是有一些研究的必要。毕竟h5已有的项目直接上webview就好了，但是老的wx程序无法直接移植到h5。目前还没有看到有这方面的转换器出现。
还有就是如果这个框架是为了两端统一而出现的，我觉得他还缺少在编译时对两端不同逻辑代码的一个区分支持，比如一些source上的应对两端环境的注释块或者环境变量这一类的。目前看文档上，这种功能需要自己做适配和判断，如果框架能够提供就更好了…
说的有点乱，临时想到的，就这样吧…
期待作者来回复更多相关…
-------update-------
今天花了几个小时把之前新浪天气通的一个vue单页给做了下转换，说一下体验。![]()
整个转换过程时间比较久，主要是以下几个原因：
1，我们的天气页面有一个曲线图是拿dom绘制的，然后实例化到页面中，没有走vue的组件系统，因为可能还要在一些zepto页面使用，所以这部分报错不兼容，找到删了。
2，这套页面时在app内嵌的环境的，所以还需要剥离一些jsbridge部分的代码，需要剔除。
3，因为发ajax请求需要使用微信小程序里的wx.request这种api，不兼容得改一下。
4，css有一些hack报错得改一下。
5，脚手架目录结构不一样，需要手工调整一下。
6，初始化组件的方式不一致，需要简单的修改下，入口必须放到page里，之前我们的入口也是components。
8，静态资源的限制，属于小程序的，所以这里需要对静态资源，比如图片，font字体做一些特殊的webpack配置，这不属于mpvue的问题，自己配置下解决就好了。
9，项目是ts写的，自己加个loader就好。
其他的不涉及DOM，BOM的，该删的也要删一会，整体转了有3，4个小时吧，以上这些问题。最后效果还是不错的，帮team的趟一下坑。
总结一下，mpvue对组件的转换支持真的很棒，只要注意了文档和我上面说的几点，稍加改造一个vue应用转小程序就实现了。
转播
