为什么要选择megalo???

[yzw2017]

如今社区出现了大量的小程序框架，美团的mpvue，京东的taro，滴滴的mpx，他们的出现解决了小程序的一些不足，以及他们公司的业务需求。但是megalo我在文档并没有看到你们的特色，举个例子,mpvue是美团第一个开源的基于vue开发小程序， mpx是滴滴开源的基于vue开发小程序，但是他是增强型框架，其他的是编译型的，但是megalo的出现，跟mpvue和mpx2个框架又有什么区别，如果单单都是基于vue开发，为什么不选mpvue和mpx？这对于开发者选择来说非常重要

[geminate]

我的理解，mpx 和 mpvue 暂时在多端小程序异构上还不是那么完善。
mpvue只支持微信，mpx 只支持 微信和支付宝，而 taro 是 使用的 react 语法。
开发者期望有一个 基于vue语法的 taro 框架出现（微信、支付宝、百度、头条、h5等多端异构），虽然现在 magalo 还未达到期望，但有至少有这个多端的发展趋势

[luanwulin]

mpvue对我来说有两个很大的bug，第一个是页面跳转后上一个vue实例不会释放，重新跳回那个页面会导致数据依然是离开的状态不会初始化。另一个是不能在模板上用函数，这个真的很恼火
mpx都不能叫vue了吧，完全是用了单文件思路重新包了一次小程序语言，既然这样为啥不直接用小程序语言写。

[elcarim5efil]

在做 megalo 之前，我们做了一个叫 mpregular 的小程序框架，也是启发自 mpvue 的，主要为了匹配我们自身的技术栈。在做的时候，发现如果参考原本 mpvue 的实现模式，在模版语法的支持以及数据更新性能上会有所限制，于是我们改进了实现的方式。

megalo 则是这套实现方案的 vue 版本。相对于 mpvue 而言，最大的不同是 megalo 是基于 vnode 的数据映射，框架会从 vnode 上收集数据再更新到视图（mpvue 目前是从 vm 上收集数据）。二者的区别在于，基于 vnode 收集数据，可以直接获取视图层需要展示的数据并排除一些非展示数据，进而可以支持更多 vue 的模版语法，包括函数调用、filter、scoped-slot 等。另外将 setData 的数据控制在更小的范围，只有视图层用到且发生变化的数据才会进行数据更新。详细的说明可以参考文章。

正式开源之后，接收到社区的反馈，我们也发现目前一些不足的地方，也在不断改进完善。关于框架的选择，最好是根据自己实际的业务场景、技术栈、人员构成进行判断。没有哪个框架是绝对最好的，只有是否适合的场景。我们有许多 h5 应用会向小程序迁移，因此尽可能保持与 h5 端一致的开发模式，减少迁移的成本和工作量，提升效率，所以对于我们来说，更多的特性支持可能是比较看重的点。

关于多端同构的问题，这当然是最理想的状态。但是在实际场景下，我们发现小程序和 h5 的交互、业务会有些差异，所以完全基于一套代码生成多个端应用的模式在这种情况下，可能带来的是后期维护的困难。当然，这是从实际业务出发的考量，多端同构的方向我们也会继续探索和尝试。

[yejinjian]

@elcarim5efil 我们目前在用mpvue 的确看到mpvue的一些不足，比如@luanwulin 列的问题，但是你列出的“megalo 是基于 vnode 的数据映射” 我觉得本质还是不如mpvue的基于vm的数据同步，vnode结果类似dom, 先通过vue的vm数据映射到vnode 然后提取vnode为数据然后Page.setData 效率反而不高，我目前了解最好的做法还是wepy2 中的做法放个钩子在vue observe中 把数据更新记录下来，然后限制setData触发频率。 这样优化mpvue setdata前需要diff的损耗。

[elcarim5efil]

@yejinjian

首次进行数据更新时，小程序视图层数据是空的，diff 的结果是全量进行更新。在开发时，如果不注意，将所有数据都设置到 vm 上时，会将一些视图层所不需要展示的数据更新过去，性能损耗比较严重。这一个问题在我们重构商详页时发现的。

vnode 上的数据是视图实际所需要的数据，包括 filter、复杂表达式、v-html 等语法的计算结果，所以这种方式能够较好地支持 Vue 的一些模版语法特性。scope-slot 也是基于 vnode 的映射去实现的。

至于 vdom diff 的性能损耗，确实可能会比 wepy2 的计算量大，但在特性和性能之间有时会需要一定的取舍和平衡。mpvue 目前应该也是需要 render vdom 并进行 diff 的，不过它在进行数据同步时没有利用 vnode。