迫切希望支持的新端投票

[beatles-chameleon]

• call 1 快应用 【进行中】
• call 2 字节跳动小程序 【done】
• call 3 React Native
• call 4 Flutter 【调研中】
• call 5 先开放 扩展新端 标准接口【done】

非常欢迎加入扩展新端共建工作，可以先看看一下资料，有兴趣可以加入QQ群联系我们，过程中的技术细节会全力支持。
1、扩展新端教程：https://cml.js.org/doc/extend/extend.html
2、字节跳动扩展小程序日志：https://mp.weixin.qq.com/s/7nsgH7Ow0RkCV12zxiVl7Q
3、字节跳动小程序扩展实现仓库：https://github.com/chameleon-team/cml-tt-sets
4、快应用扩展实现仓库：https://github.com/quickappcn/cml-extplatform-quickapp/tree/fix-runtime

更多规划了解

[uxiew]

2->4；
理由：我觉得小程序目前市场还是比重最大的，而且很多人也都是对统一多端小程序感兴趣而来的，所以如果先统一小程序端开发，那么未来应该会有更多人加入和使用。
其他端相比小程序端，应该会更耗时耗力。
所以建议先统一小程序端开发。（我觉得我有理有据😹）。

---

额...还有 QQ小程序 ，提一下~

[Sunery0408]

5

[phantomk]

3 | 4

[imccfly]

3，4

[zhangyugege]

4

[haitaodesign]

3

[yinjun1992]

5

[han-xiaowei]

4

[maslow]

4

[David-C-gd-y]

3，4

[mojerro]

3.4

[chaochuandea]

4

[neostfox]

5. 接口属于基础设施层。要先走的。

[world56]

2

[kerwin-cn]

4

[program-spiritual]

5

[yutiansut]

5 , 3

[goodheart]

5

[GrapevineLin]

5

[CirnoBreak]

3, 4

[mifanj]

4

[jy1989]

3, 4

[mangyan-zz]

1

[mangyan-zz]

3

[gagaboy]

call 1，5
理由如下：
1）作为一个有理想和目（ye）标（xin）的项目，发展的阶段蓝图一定不能以个人意愿或者开发者喜好作为主要导向，而是应该以市场和环境为主要目标。所以，看下整体的移动市场的手机品牌分布情况，也是优先快应用；
2）市面上有很多各种各样的小程序类的支持需求，那么 5 先开放 扩展新端 标准接口，这就势在必行。同时对于新端来说，如何衔接，方式方法也可以逐步标准化开放出来，利用社区的力量来完善各端的能力。

[netputer]

• call 1 快应用
• call 2 字节跳动小程序
• call 3 React Native
• call 4 Flutter
• call 5 先开放 扩展新端 标准接口

个人想法：5 > 1 > 2 > 3 > 4

首先 5 作为 CML 底层需要要先行，后续所有事情都是基于这一步；其次快应用整体架构和小程序差异较大，如果能完美适配快应用对 CML 完善底层有帮助；然后原生部分已经有 Weex 了，再搞 RN 或 Flutter 成本很大而性价比并不高，所以建议先头条小程序再做其它前瞻探索

[wowtrxqn]

3

[feengqi]

5

[licong]

4 > 5

[edministrator]

先正常跑起来在说！
5>2>...

[smwsk]

2

[al8n]

2

[thumb0422]

现在小程序端 太多了，太多了，保不齐下一个就是京东小程序等等，个人建议先不要搞这些，精力也有所不及。

[rudyxu1102]

1呀

[Eden-Harris]

5>2>4 | 1和3觉得可以不用考虑

5. 统一&完善接口 肯定优先保证能用，好用，实现基础的 支付+推送+统计+第三方登陆和分享，来吸引壮大开发人群和活跃社区，很多跨平台项目仅仅实现了界面跨平台，但是绝大部分的前端并不会原生ios和原生Android开发，更不会自己开发插件，原生SDK方面他们依赖官方或者社区力量；
2. 全平台小程序 目前各大平台都在争取流量，这已经反应到开发市场上去，如今的uni-app就很明白，所以小程序很重要；
4. Flutter 对flutter的支持对APP性能的帮助和对移动端开发者的吸引力就不说了，如果结合CML实现原生渲染+热更新那就太棒了

1. android端 快应用 快应用虽然不错，但是无法在IOS端实现，未来还是需要依靠 PWA
3. React Native RN就算了吧，反而耗费人员和成本，而且和VUE语法相差太大，有那功夫程序员肯定更接受先进的Flutter.

[rayy-li]

4

[luvletterldl]

我希望优先支持Flutter，4

[kiko111]

2

[songxiaoliang]

3

[foreverpw]

4

[tianlu1677]

qq 小程序

[beatles-chameleon]

@tianlu1677 QQ小程序已经支持了：https://github.com/didi/chameleon/blob/0.3.x-alpha/CHANGELOG.md#features-1

[xiongtj]

迫切的需要4

[slipkinem]

这个，我想说能不能顺便支持下钉钉小程序😁

[rj9676564]

迫切3

[beatles-chameleon]

迫切3

已经支持 weex 的情况下，支持第三条的好处是利用起 RN 的组件生态，价值不那么明显~
欢迎贡献https://cmljs.org/doc/extend/extend.html

[rj9676564]

迫切3

已经支持 weex 的情况下，支持第三条的好处是利用起 RN 的组件生态，价值不那么明显~
欢迎贡献https://cmljs.org/doc/extend/extend.html

从全局策略确实如此。

自己的实际情况是，把已有RN部分转成小程序和网页，并能够持续跟进更多小程序平台。

[beatles-chameleon]

迫切3

已经支持 weex 的情况下，支持第三条的好处是利用起 RN 的组件生态，价值不那么明显~
欢迎贡献https://cmljs.org/doc/extend/extend.html

从全局策略确实如此。

自己的实际情况是，把已有RN部分转成小程序和网页，并能够持续跟进更多小程序平台。

支持 RN 的意思是支持 CML 项目转成 RN，而不是用 RN 开发哦~
如果已有项目用的 RN，短期来说迁移成本较低而已

[rj9676564]

了解。意义也是实现平滑升级的过程。目前chamaleon不支持rn，需要同时集成weex和rn，对项目来说是个不小的挑战。如果集成，需要同步rn、weex和原生之间的互调、状态同步、navigation栈等问题。在项目切换到chamelon且实现flutter，能够实现移动端过度到flutter。另外其他类似的chamaleon的方案在处理rn时不够稳定。 另外想问to rn这块难度，想贡献一点自己的力量。

…

在 2019年8月13日，下午12:07，beatles-chameleon ***@***.***> 写道： 迫切3 已经支持 weex 的情况下，支持第三条的好处是利用起 RN 的组件生态，价值不那么明显~ 欢迎贡献https://cmljs.org/doc/extend/extend.html 从全局策略确实如此。 自己的实际情况是，把已有RN部分转成小程序和网页，并能够持续跟进更多小程序平台。 支持 RN 的意思是支持 CML 项目转成 RN，而不是用 RN 开发哦~ 如果已有项目用的 RN，短期来说迁移成本较低而已 — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[beatles-chameleon]

了解。意义也是实现平滑升级的过程。目前chamaleon不支持rn，需要同时集成weex和rn，对项目来说是个不小的挑战。如果集成，需要同步rn、weex和原生之间的互调、状态同步、navigation栈等问题。在项目切换到chamelon且实现flutter，能够实现移动端过度到flutter。另外其他类似的chamaleon的方案在处理rn时不够稳定。 另外想问to rn这块难度，想贡献一点自己的力量。
…
在 2019年8月13日，下午12:07，beatles-chameleon @.***> 写道： 迫切3 已经支持 weex 的情况下，支持第三条的好处是利用起 RN 的组件生态，价值不那么明显~ 欢迎贡献https://cmljs.org/doc/extend/extend.html 从全局策略确实如此。 自己的实际情况是，把已有RN部分转成小程序和网页，并能够持续跟进更多小程序平台。 支持 RN 的意思是支持 CML 项目转成 RN，而不是用 RN 开发哦~ 如果已有项目用的 RN，短期来说迁移成本较低而已 — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

非常欢迎加入扩展新端共建工作，可以先看看一下资料，有兴趣可以加入微信群联系我，过程中的技术细节会全力支持。
1、扩展新端教程：https://cml.js.org/doc/extend/extend.html
2、字节跳动扩展小程序日志：https://mp.weixin.qq.com/s/7nsgH7Ow0RkCV12zxiVl7Q
3、字节跳动小程序扩展实现仓库：https://github.com/chameleon-team/cml-tt-sets
4、快应用扩展实现仓库：https://github.com/quickappcn/cml-extplatform-quickapp/tree/fix-runtime

[beatles-chameleon]

这个，我想说能不能顺便支持下钉钉小程序😁

钉钉小程序和支付宝小程序一样，基本不用改动

[aoeng]

win 客户端不考虑一下吗 ? T=T

[jaychoumylove]

建议支持winPhone小程序

[knight-peter]

4>5
目前小程序还是以微信为主，如果只是微信小程序和网页，那我宁愿用原生的来写，这样遇到的坑最少。对week不是很信任，感觉是个快淘汰的东西，不想花时间去学习。
如果能对flutter也一起支持，那chameleon对我的吸引力就很大了。

[zc20081989]

我们是第三方小程序服务商，客户可以通过我们平台制作自己的小程序，有的客户希望小程序可以支持多端，比如百度小程序或者头条小程序
目前我们只支持微信小程序且使用的是原生开发的，因为之前调研的时候chameleon还不成熟，就没有使用
有没有可以快速从原生小程序转chameleon的方案

[Guo-Zhang]

您好！

我的产品是课程平台，除了移动端，还包括PC Web、Win客户端、Mac客户端也计划支持。目前我们的选型是模板语言做Web+微信小程序原生+Flutter做iOS Android Win Mac Linux。下一步的计划是用跨平台小程序框架代替微信小程序原生，Flutter for Web代替模板语言。

从我们的需求考虑，最有吸引力的首先是统一所有现有的类小程序，比如快应用等等。然后是支持Flutter，特别是可以支持桌面端，这样我们可以完全只用一套框架做客户端。

[Guo-Zhang]

您好！

我的产品是课程平台，除了移动端，还包括PC Web、Win客户端、Mac客户端也计划支持。目前我们的选型是模板语言做Web+微信小程序原生+Flutter做iOS Android Win Mac Linux。下一步的计划是用跨平台小程序框架代替微信小程序原生，Flutter for Web代替模板语言。

从我们的需求考虑，最有吸引力的首先是统一所有现有的类小程序，比如快应用等等。然后是支持Flutter，特别是可以支持桌面端，这样我们可以完全只用一套框架做客户端。