eros： https://bmfe.github.io/eros-docs
差别：eros多页面没用使用路由

我们尽快写一篇迁移文档~

eros： https://bmfe.github.io/eros-docs
差别：eros多页面没用使用路由

试用了下eros并对比了和chameleon的差异，总的来讲，eros是比较存粹的weex项目，因此语法层面的迁移可以参考 这篇文章 。看了一下你在另外一个issue下的回复，感觉主要是对于路由方面迁移的问题，这里展开讲一下：

路由方面eros和chameleon的设计理念是不同的。eros项目在打包时是每个页面打包成了一个js bundle，每一个页面对应一个原生的view，它是没有"应用"这个概念的；chameleon是将一个项目内的所有页面打包成一个js bundle，应用内页面的跳转都在同一view下进行，多个chameleon项目才对应多个view， 这样设计weex应用主要是因为这样更能够对应web端单页应用、小程序应用的概念，对于跨端项目的定义是更加统一的，具体的也可以看下这个 issue 下的回复。

然后说下路由怎么迁移， 针对你的场景，一个TAB可以是一个chameleon项目，然后TAB内的页面走应用内的跳转，TAB之间的跳转用(cml.open)[https://cmljs.org/doc/api/open.html#open]。 对于weex页面与客户端页面的跳转，本质上是一个weex页面与原生页面的通讯问题，可以参考jsbridge的设计方法，实现一套通讯机制，这样就不止能够做到页面的互跳，而是更多能力的支持。

eros： https://bmfe.github.io/eros-docs
差别：eros多页面没用使用路由

试用了下eros并对比了和chameleon的差异，总的来讲，eros是比较存粹的weex项目，因此语法层面的迁移可以参考 这篇文章 。看了一下你在另外一个issue下的回复，感觉主要是对于路由方面迁移的问题，这里展开讲一下：

路由方面eros和chameleon的设计理念是不同的。eros项目在打包时是每个页面打包成了一个js bundle，每一个页面对应一个原生的view，它是没有"应用"这个概念的；chameleon是将一个项目内的所有页面打包成一个js bundle，应用内页面的跳转都在同一view下进行，多个chameleon项目才对应多个view， 这样设计weex应用主要是因为这样更能够对应web端单页应用、小程序应用的概念，对于跨端项目的定义是更加统一的，具体的也可以看下这个 issue 下的回复。

然后说下路由怎么迁移， 针对你的场景，一个TAB可以是一个chameleon项目，然后TAB内的页面走应用内的跳转，TAB之间的跳转用(cml.open)[https://cmljs.org/doc/api/open.html#open]。 对于weex页面与客户端页面的跳转，本质上是一个weex页面与原生页面的通讯问题，可以参考jsbridge的设计方法，实现一套通讯机制，这样就不止能够做到页面的互跳，而是更多能力的支持。

感谢大佬回复。
我当前的场景先描述清楚：APP有4个TAB(Tab1、Tab2、Tab3、Tab4) ,其中Tab1、Tab2是weex实现,其余的是Native的。所有tab都有可能去打开如 商品页、评论页等weex页面和部分Native页面。小程序方面可以理解为APP端大部分的Native页面的，在其他端就被阉割掉了去要求下载APP，现在这种情况的确是多端不太统一的一个状态。

问题一：如果我是多个Tab多个项目。对应的其他端如何处理呢（如小程序）。
问题二：上面所说的（商品页、评论页等weex页面）这些公用的WEEX页面如何处理。
要是我描述的不太清楚。可以在chameleon探讨

eros： https://bmfe.github.io/eros-docs
差别：eros多页面没用使用路由

试用了下eros并对比了和chameleon的差异，总的来讲，eros是比较存粹的weex项目，因此语法层面的迁移可以参考 这篇文章 。看了一下你在另外一个issue下的回复，感觉主要是对于路由方面迁移的问题，这里展开讲一下：
路由方面eros和chameleon的设计理念是不同的。eros项目在打包时是每个页面打包成了一个js bundle，每一个页面对应一个原生的view，它是没有"应用"这个概念的；chameleon是将一个项目内的所有页面打包成一个js bundle，应用内页面的跳转都在同一view下进行，多个chameleon项目才对应多个view， 这样设计weex应用主要是因为这样更能够对应web端单页应用、小程序应用的概念，对于跨端项目的定义是更加统一的，具体的也可以看下这个 issue 下的回复。
然后说下路由怎么迁移， 针对你的场景，一个TAB可以是一个chameleon项目，然后TAB内的页面走应用内的跳转，TAB之间的跳转用(cml.open)[https://cmljs.org/doc/api/open.html#open]。 对于weex页面与客户端页面的跳转，本质上是一个weex页面与原生页面的通讯问题，可以参考jsbridge的设计方法，实现一套通讯机制，这样就不止能够做到页面的互跳，而是更多能力的支持。

感谢大佬回复。
我当前的场景先描述清楚：APP有4个TAB(Tab1、Tab2、Tab3、Tab4) ,其中Tab1、Tab2是weex实现,其余的是Native的。所有tab都有可能去打开如 商品页、评论页等weex页面和部分Native页面。小程序方面可以理解为APP端大部分的Native页面的，在其他端就被阉割掉了去要求下载APP，现在这种情况的确是多端不太统一的一个状态。

问题一：如果我是多个Tab多个项目。对应的其他端如何处理呢（如小程序）。
问题二：上面所说的（商品页、评论页等weex页面）这些公用的WEEX页面如何处理。
要是我描述的不太清楚。可以在chameleon探讨

说一下个人看法，不一定正确，当然我们也可以继续讨论：
对于你这边的场景，因为还要考虑小程序，忽略之前eros的影响，个人仍然建议将所有非Native的资源打包成一个bundle，也就是总共只有一个项目，这样的可以解决：

1. weex与微信小程序的统一问题
2. 一些公共weex页面的复用问题

对于比如小程序引导下端和端内打开某一页面这种差异化需求用多态也可以搞定
至于weex与native的通讯上面的回复中已有介绍，可以参考