【讨论】新的小程序组件框架 glass-easel

[CommanderXL]

前段时间随着 skyline 的推出，搭配着使用新的底层小程序组件框架 glass-easel，从文档上来看：

1. 相对于之前的 exparser 旧版组件框架更好的性能和更多的特性；
2. 可以跨 web；

当然文档上也提到了这个后端概念，也意味着可以将小程序的代码作为上层的 dsl，中间借助 glass-easel 作为组件逻辑层，然后去适配不同的后端环境来做“跨端”（donut）。

这套技术方案看起来也是和目前社区主流的运行时框架(例如Kbone、Taro)的思路正好相反，因为这些运行时框架正好是借助上层的例如(vue、react)等作为dsl，在小程序这个后端环境下做适配，借助模板递归的能力去完成最终的渲染。当然运行时框架所绕不开的比较大的问题之一就是性能问题，几个性能卡点：

1. 首屏初次渲染，数据量大；
2. diff 数据，如果 template 没有做优化，会导致逻辑层往渲染层发送的数据量比较大；
   1. key 的长度比较多；
   2. setData 的数据也比较多；（核心还是因为运行时方案是基于 vnode tree 的 diff 去搜集需要更新的数据）

看起来 glass-easel 这套方案将小程序作为上层的dsl，这样后续在做跨端项目可以比较好的解决：

1. 效率问题；（同构：可以直接跨web了，一码多端，还有native）
2. 性能问题；（小程序环境下的渲染还是走原生小程序的渲染模式，而非运行时的方案，直接绕开了上述几个运行时方案的性能卡点）

不过看起来 glass-easel 这套方案感觉还有一段时间要走，感觉最大的还是生态问题：毕竟运行时方案上层用的vue、react等，对应的生态（组件库、工程化等等）都非常的完善了。

不知道对于 Kbone 来说后续的规划是什么？从同构的场景来说完全是两种不同的思路。（不清楚是不是同一个团队去维护的）

[JuneAndGreen]

两者确实是不同思路，因为这两个方案本身就是应对不同场景而产生的，kbone 当初是为了快速将内部某些 web 产品页面转成小程序形态而诞生，glass-easel 则是为了将小程序适应到不同的渲染后端而诞生（比如 skyline）。如果使用 kbone 的话，你可以理解为层级由上到下是这样的：web 代码 -> kbone 适配层 -> glass-easel -> 渲染后端（webview/skyline/其他后端），两者本身并不是冲突的。

至于 kbone 本身是不想做得过于重的，只要专注于让部分 web 代码可以直接跑到小程序上就够了。事实上现在的小程序形态可能更适合 kbone 与原生混合的形式（比如部分页面采用 web 编写使用 kbone 混入到原生小程序中），kbone 只是提供了一套适配方案，他跟 taro 乃至原生小程序都不算有竞争关系，因为各有适合的场景，开发者按需求选择即可。