Taro: 既然kbone已经可以用了，为什么还要发布3.0.0作为正式版？

[xmsz]

问题描述

复现步骤

/**
 * 这段注释后可以贴代码
 * 提供完整可复现的代码和整理好代码格式，有助于我们快速定位问题，节省你我时间
 * 代码提供不全或代码格式混乱的 issues 【有可能会被忽略】
 * 
 * 查看如何插入代码：https://coding.net/help/doc/project/markdown.html#i-5
 */

期望行为

报错信息

系统信息

补充信息

如果您有功能上的建议，可以提到 FeatHub

使用上的问题，欢迎在「Taro 社区」一起交流

大概看了Taro 3。应该走和kbone一样的路。如果是这样，为什么还要退出3。而不直接使用kbone。

毕竟kbone还是官方维护。

[cncolder]

因为不完全相同, 对 vue2 的支持确实和 kbone 类似, 但对 react 的支持则不同.
https://github.com/NervJS/taro/blob/docs/docs/difference-to-others.md

[shenghanqin]

我想要多端呀。比如我这边想弄微信、qq、web、抖音等常见，knone并没有呀。

[xmsz]

我想要多端呀。比如我这边想弄微信、qq、web、抖音等常见，knone并没有呀。

多端其实和这个没关系，Kbone也能实现。原理都差不多

[xmsz]

因为不完全相同, 对 vue2 的支持确实和 kbone 类似, 但对 react 的支持则不同.
https://github.com/NervJS/taro/blob/docs/docs/difference-to-others.md

明白，就是

1. react方面，使用react-reconciler来精简不必要的react浏览器兼容代码
2. dom更新方面，使用setData路径来优化传输量，提升小程序性能

[admiao]

因为不完全相同, 对 vue2 的支持确实和 kbone 类似, 但对 react 的支持则不同.
https://github.com/NervJS/taro/blob/docs/docs/difference-to-others.md

明白，就是

1. react方面，使用react-reconciler来精简不必要的react浏览器兼容代码
2. dom更新方面，使用setData路径来优化传输量，提升小程序性能

大佬 ， 意思是在3中 用React 比 Vue 更有优势吗 ？

[xmsz]

因为不完全相同, 对 vue2 的支持确实和 kbone 类似, 但对 react 的支持则不同.
https://github.com/NervJS/taro/blob/docs/docs/difference-to-others.md

明白，就是

1. react方面，使用react-reconciler来精简不必要的react浏览器兼容代码
2. dom更新方面，使用setData路径来优化传输量，提升小程序性能

大佬 ， 意思是在3中 用React 比 Vue 更有优势吗 ？

理论上，是想要达到无关上层框架。所以没有优势之分。
其次关于第一点的优化，理论上也只是增加体积而已，也没有优势

所以，选择无关框架，无关版本

[cncolder]

@admiao 至少目前跟 vue2 相比, 是的.
未来有计划支持 vue3, 两者就追平了.

react-reconciler 最主要的优势是复杂度治理, 简单的方案才能在短时间内更趋于稳定.
相比 taro2 而言, 则是深耕 ast, 无止境的兼容各种语法, 永远也不可能做到完美.

[xmsz]

@admiao 至少目前跟 vue2 相比, 是的.
未来有计划支持 vue3, 两者就追平了.

react-reconciler 最主要的优势是复杂度治理, 简单的方案才能在短时间内更趋于稳定.
相比 taro2 而言, 则是深耕 ast, 无止境的兼容各种语法, 永远也不可能做到完美.

这个就是我原来的疑问所在，如果是taro版本上，3和2完全不一样的编译方式。而3.x版本运行时编译方式，kbone已经做到了，而且是官方维护。那么感觉[email protected]就没啥必要

而框架版本的话，因为无关上层框架，所以[email protected] [email protected]都是照样跑，我们项目就是[email protected]在kbone上跑得好好的，毕竟抹平（模拟）了环境，所以完全做不用兼容或者精简

所以就在想，是不是有些taro的独有的优势？

而文章中看到的两点来说，第二点对于项目来说是比较意义。毕竟小程序上，安卓机器没有优化真的是玩不动。

不过这一点我在kbone那里也回复，未来可能会加上，不过意思是这个可能影响不大

还有就是设想一下，官方维护的好处，除了亲儿子属性，以后可能就没有什么小程序原生开发了。也就不用在用别的方案了

[cncolder]

@xmsz 见仁见智吧, 你相信官方, 就跟着官方走.

你的分析证明你很喜欢思考, 那么你可以反观一下历史, wx 乃至 tx 这几年以来对前端开源领域做过哪些贡献, 他们的贡献主要集中在设计领域.

选择哪个框架是基于每个人的思考和判断(或者跟风), 就我个人的观点来看, 我并不认为 kbone 有官方背书就代表它一定能超越谁, 反而会成为一种局限性.

kbone 的好处是显而易见的, 就是在微信小程序中集成了框架, 这一点其他框架永远都比不上.

[admiao]

移动端选择Vue 无疑是为了体积小而性能出众 ， 但 ts 的不友好 和 vue3 至今还是没有正式版 也是我对vue 的无奈

[xmsz]

移动端选择Vue 无疑是为了体积小而性能出众 ， 但 ts 的不友好 和 vue3 至今还是没有正式版 也是我对vue 的无奈

typescript挺友好的，https://github.com/vuejs/composition-api/blob/master/README.zh-CN.md
@2.x版本确实没考虑到，现在完全ok了

[xmsz]

@xmsz 见仁见智吧, 你相信官方, 就跟着官方走.

你的分析证明你很喜欢思考, 那么你可以反观一下历史, wx 乃至 tx 这几年以来对前端开源领域做过哪些贡献, 他们的贡献主要集中在设计领域.

选择哪个框架是基于每个人的思考和判断(或者跟风), 就我个人的观点来看, 我并不认为 kbone 有官方背书就代表它一定能超越谁, 反而会成为一种局限性.

kbone 的好处是显而易见的, 就是在微信小程序中集成了框架, 这一点其他框架永远都比不上.

可以的，理性讨论

腾讯确实之前贡献太小，不过包括阿里也好，其实内部系统和社区都是不同步的。不过这都是时间会解决的事。（腾讯开源很少，但是产出文章还是很多）（贡献肯定还是比不上蚂蚁，输出的是价值观）

选择框架确实是每个团队或者个人的选择，这点同意。

我们团队选择kbone的理由，最大的理由确实官方维护。求稳是第一要义，就像买电器，有条件情况下还是选官方或者老牌，毕竟短时间不会跑路。像锤子、美图这种火过也做得确实比其他好，但现在呢

[shenghanqin]

所以，仁者见仁智者见智，各有需求，喜欢就好，开心就好。