glass-easel未来会彻底替代exparser并应用于webview上吗 about glass-easel HOT 3 CLOSED

先回答标题的问题：会成为首选推荐。

• 以小程序目前的整体架构上看，数据通信其实并不是主要开销，远低于运算开销。
• 除非数据长度很大，数据通信自身的开销与数据量并不成正比，只是有一定的正相关。
• exparser 体系并不只是传递 data 数据本身，还需要传递很多 metadata （尤其是在启动时），理论上总数据量还真不一定会少。
• 样式表事实上是静态代码，并不需要传递（大量使用 style attr 从来就不是什么好的做法）。
• VirtualNode 信息在 exparser 上也是需要关心的，并没有什么差异。

from glass-easel.

先回答标题的问题：会成为首选推荐。

• 以小程序目前的整体架构上看，数据通信其实并不是主要开销，远低于运算开销。
• 除非数据长度很大，数据通信自身的开销与数据量并不成正比，只是有一定的正相关。
• exparser 体系并不只是传递 data 数据本身，还需要传递很多 metadata （尤其是在启动时），理论上总数据量还真不一定会少。
• 样式表事实上是静态代码，并不需要传递（大量使用 style attr 从来就不是什么好的做法）。
• VirtualNode 信息在 exparser 上也是需要关心的，并没有什么差异。

关于最后一条，exparser的逻辑层（v8/jscore ）也有VirtualNode吗？是逻辑层和视图层各有一套同构VirtualNode对吗？

另外glass-easel架构看起来和react-native有点像了，请教下，当前glass-easel的diff算法（最长升子序列算法）比一般的双端diff算法（如snabbdom类的）有确定的什么优势吗？

from glass-easel.

这里的具体逻辑很复杂，很难在这个帖子里面简单说明。总之事实上是 exparser 也需要一些“结构信息”，包括 VirtualNode 。

所有后端分离的框架呈现的架构应该都有一定的相似性。这种相似性其实和 diff 算法是无关的（或者说相互独立的）。

目前使用的 diff 算法是一个带有特殊优化的最长升子序列算法。这个算法理论上说是一个上限相对较低、下限相对较高的算法——因为它总是需要建立额外的 map 从而带来一点点额外开销，但最差时间复杂度有保证。用这个算法主要是考虑 glass-easel 实际上只在 wx:for 列表变更时才应用这个算法，这种时候这一点点额外开销是相对不会很亏的。

from glass-easel.