kbone
kbone copied to clipboard
Tencent
小讨论一下，一般多端开发的应用场景有哪些？
目前做过的项目来说，都是强依赖小程序的api，或者需要一些『黑科技』。 没有什么地方可以进行多端开发或者需要多端开发
大家有什么项目是会用到多端开发的？
@xmsz 这个项目的初衷是为了产出一套方案支持快速迭代出微信开放社区小程序的，可以认为是 web 端和小程序端的同构方案，一套代码多端运行，降低维护成本。
说实话，多端开发什么的就是大坑，实际上大多数时候都只是技术栈统一而已。 开发的时候还得是一个平台一套代码，很少有那种真正的一次开发，到处编译的框架。 当然了，也可能是我水平不够，思考的不够全面。
说实话，多端开发什么的就是大坑，实际上大多数时候都只是技术栈统一而已。 开发的时候还得是一个平台一套代码，很少有那种真正的一次开发，到处编译的框架。 当然了，也可能是我水平不够，思考的不够全面。
这取决于条件编译的灵活度，uni-app是多端一套代码的，这样升级时，就不会多头升级，提升维护效率
我正在开发一套前端跨端开发框架（特别是移动端开发），基于 react 和观察者模式，目前遇到一些坑正在填 https://github.com/tangshuang/nautil
来说说我的想法。
单纯一套代码直接跑在多平台上是不现实的，虽然理想很丰满，但是不同的平台 api 不一样，很难抹平。现在靠谱的解决方案都是 bridge，包括 kbone，我觉得也是 bridge 方案。 有了 bridge，接下来要考虑的就是怎么把同一套代码编译为符合不同平台 api 的代码，我觉得全靠工具来做。除了工具之外，就是利用 js 语言特性，例如重写原型链方法，利用对象引用特性等，修改原代码中不适用的部分。
对于开发者而言，写代码过程中一定要有一些规则去遵守，这样才能在下游进行多端构建的时候构建出对应的端应用。一旦开发者心甘情愿的去遵守这些规则，后面会发现，写跨端应用真的很舒服，相当于把写代码和运行时完完全全解耦出来了，写代码的时候完全是按照自己的业务逻辑思路去写，而不用考虑运行时的问题，这种状态是很舒服的，是应该被追求的。
所以，小伙伴赶紧加油，把 kbone 做好，做成标杆～
@dntzhang 恩恩，我今天试了下，感觉不错。希望可以早点支持react hooks。底层这里的实现想了解下，是通过preact转为VDOM，然后再根据VDOM来使用kbone的miniprogram-element和miniprogram-render吗？ 关于kbone的原理，我看了这里的实现，好像是自己将虚拟的DOM节点递归转化为一颗DOM树(其实本质上也是虚拟的）。最大的问题可能是，如果小程序官方更新了内置组件的属性或者新增了组件，而业务需要用到的时候，要怎么比较平滑的更新（而且也依赖于包的更新）。 或许可以考虑允许用户自定义扩展内置组件。
少了一步，应该是 preact vdom再转成 js core里的dom(其实也是 vdom)，然后vdom作为数据使用kbone的miniprogram-element和miniprogram-render
补充了一篇文档，还没写完 https://github.com/Tencent/omi/blob/master/tutorial/kbone.md
react 和 preact 都支持了。要用 hook，使用 react，preact 的 hook 还要等 preact x 正式发布。
@scutcl kbone的思路和其他两个不一样，不是通过编译来保持语法一致，而是自己实现了一套runtime。所以应该不会有之前的坑。希望能搞好吧
@chenjigeng 其实我的目的也很明确，就是想用vue的方式写小程序，但是目前wepy和mpvue也都是半吊子，期望kbone不要再坑了吧
uniapp不是也用的贼溜的么
其实这主要是个生态问题。在github上，OMI的“used by”是74；而vue的是1.2m，react是3m。 一套代码用于多个平台，这绝对是个坑，一个永远填不满的坑，刚爬出来还会掉下去那种。
请问这个支持支付宝小程序的开发吗，还是只是web端和微信小程序的
很明显是不支持的。估计作者还没考虑进去呢。支付宝那又是另外一个兼容了。工作量不小~
可以关注一下 Rax，github.com/alibaba/rax 运行时方案是依赖 Kbone 的，支持微信小程序和支付宝小程序
很疑惑kbone相对于uni-app和taro这种的优势有哪几方面？先说清楚优势才敢放手用，查了半天，还是没太清楚，是h5对weui的支持，加上官方出的嘛，还是说这个的目的主要是将h5转成小程序？那想小程序转h5有工具么
很疑惑kbone相对于uni-app和taro这种的优势有哪几方面？先说清楚优势才敢放手用，查了半天，还是没太清楚，是h5对weui的支持，加上官方出的嘛，还是说这个的目的主要是将h5转成小程序？那想小程序转h5有工具么 优势：
- 没有历史包袱，可以做到小而精，且不用天天为莫名其妙的bug烦恼
- 虽然开发团队人数少，但是技术和思路确实很厉害，至少比uni-app强太多
- 官方直出，正品有保障未来也可能有一定特权，至少是和小程序开发团队共享进度，可以直接提供建议
劣势
- 只是微信小程序/h5，不支持其他平台（QQ勉强可以（毕竟QQ就是低配版抄袭微信，就是微信有的bug它也有，微信没有的它更多），其他不行）
其实挺明显的，看你的选择
如果你只要开发微信和QQ小程序，那Kbone最适合。坑少性能高。
但成年人肯定全都要。所以，如果你有多平台支持，那就Taro。稳定（因为已经好几年了，再多坑别人也踩过了），多端
如果你还需要App，那就最次的uni-app吧，能用但不友好，祝愿不要有这种场景
然后如果是说性能的话，也是看情况
如果你小程序逻辑交互简单，那三个都差不多 如果复杂的话，KBone和Taro也差不多，就是iOS啥事没有，但是安卓都会卡
很疑惑kbone相对于uni-app和taro这种的优势有哪几方面？先说清楚优势才敢放手用，查了半天，还是没太清楚，是h5对weui的支持，加上官方出的嘛，还是说这个的目的主要是将h5转成小程序？那想小程序转h5有工具么 优势：
- 没有历史包袱，可以做到小而精，且不用天天为莫名其妙的bug烦恼
- 虽然开发团队人数少，但是技术和思路确实很厉害，至少比uni-app强太多
- 官方直出，正品有保障未来也可能有一定特权，至少是和小程序开发团队共享进度，可以直接提供建议
劣势
- 只是微信小程序/h5，不支持其他平台（QQ勉强可以（毕竟QQ就是低配版抄袭微信，就是微信有的bug它也有，微信没有的它更多），其他不行）
其实挺明显的，看你的选择
如果你只要开发微信和QQ小程序，那Kbone最适合。坑少性能高。
但成年人肯定全都要。所以，如果你有多平台支持，那就Taro。稳定（因为已经好几年了，再多坑别人也踩过了），多端
如果你还需要App，那就最次的uni-app吧，能用但不友好，祝愿不要有这种场景
然后如果是说性能的话，也是看情况
如果你小程序逻辑交互简单，那三个都差不多 如果复杂的话，KBone和Taro也差不多，就是iOS啥事没有，但是安卓都会卡
讲道理我们只需要考虑微信小程序和h5，其他的端直接加载h5链接，暂时放弃了，主要是怕h5兼容性问题，等更成熟了在切换
很疑惑kbone相对于uni-app和taro这种的优势有哪几方面？先说清楚优势才敢放手用，查了半天，还是没太清楚，是h5对weui的支持，加上官方出的嘛，还是说这个的目的主要是将h5转成小程序？那想小程序转h5有工具么 优势：
- 没有历史包袱，可以做到小而精，且不用天天为莫名其妙的bug烦恼
- 虽然开发团队人数少，但是技术和思路确实很厉害，至少比uni-app强太多
- 官方直出，正品有保障未来也可能有一定特权，至少是和小程序开发团队共享进度，可以直接提供建议
劣势
- 只是微信小程序/h5，不支持其他平台（QQ勉强可以（毕竟QQ就是低配版抄袭微信，就是微信有的bug它也有，微信没有的它更多），其他不行）
其实挺明显的，看你的选择
如果你只要开发微信和QQ小程序，那Kbone最适合。坑少性能高。
但成年人肯定全都要。所以，如果你有多平台支持，那就Taro。稳定（因为已经好几年了，再多坑别人也踩过了），多端
如果你还需要App，那就最次的uni-app吧，能用但不友好，祝愿不要有这种场景
然后如果是说性能的话，也是看情况
如果你小程序逻辑交互简单，那三个都差不多 如果复杂的话，KBone和Taro也差不多，就是iOS啥事没有，但是安卓都会卡
单看react的化，讲真 kbone 性能肯定没有taro3好， 多了一层 domRender 如 React-dom（pruduction-min包116K） 和 dom 和 bom hack， setData的时候数据巨大
单看react的化，讲真 kbone 性能肯定没有taro3好， 多了一层 domRender 如 React-dom（pruduction-min包116K） 和 dom 和 bom hack， setData的时候数据巨大
我们自己有项目(逻辑比较复杂的) 实际看差不多情况 就是iOS写得再烂都是流畅 安卓写得再好还是会卡 不过实现方式上还得作者来回答比较好
