Tencent
无界还会更新吗，后续有什么迭代计划吗
做无界微前端的时候，当时最大的出发点是简化接入的成本，让业务在不理解微前端原理的前提下开箱即用。无界刚完成开发的时候，我们的低代码业务是第一个接入的项目，这个低代码业务代码非常庞大散落很多npm包，可以说几乎没有做任何修改就接入进来了，换成其他微前端框架有点不能想象，第一次被自己做的工具给爽到。
无界大量利用webcomponent和iframe这样的原生能力，在隔离度和易用性方面有很大的提升，但是从目前实践来看，微前端还是没有银弹。
要让webcomponent和iframe连接起来需要做代理工作，而很多属性的代理是矛盾的比如：popperjs希望元素的ownerDocument不要被劫持，这样弹窗冒泡就可以准确的计算位置不至于偏移，而兼容react17以下事件代理丢失需要劫持ownerDocument到iframe的document，有些库会从element.ownerDocument.defaultView中获取window所以也要劫持，所以框架层面只能劫持而很多组件的弹窗位置就不对也没办法解决了；我想实现一个空白的和主应用同源的iframe目前都还是无法实现；iframe销毁之后点击浏览器回退是没有办法做路由同步。
最终我发现了一个真理：没有微前端可以做到问题收敛，层出不穷的问题根源在于官方没有提供完美的沙箱。要接入微前端就必须要明白微前端内部运行原理以便有坑的时候不至于束手无策，这极大的提高了使用微前端的门槛，和我当初的预想偏离的越来越远。
我看国外的开发者似乎就没有开源出什么微前端框架，除了一个single-spa，非常明智的选择。我觉得在官方没有提供完美沙箱之前技术不应该做这个缝合怪，让很多产品层面需要解决的问题都丢给技术用微前端来解决导致微前端泛滥。
无界未来怎么规划呢？无界有两个方向可以做： 1、将更底层的能力暴露出来，所有使用上的问题开发自行通过修改无界底层能力来解决，框架作者只对底层能力负责 2、框架层面去兼容所有的case，目前来看已经不现实了
所以只有第一条路可选，但是这样的话就对开发者有很高的要求了，目前开发者其实也可以自行fork一份进行魔改来实现。而现实是大量的开发者还在询问跨域怎么解决...，开发者还是需要一套完整的方案，不想去关心微前端里面庞大的细节。矛盾已经不可调和，作为框架开发者也没有什么办法可以解决。
后续如果没有更好的沙箱出现，无界可能不做大的迭代更新了，大家也可以讨论一下无界下一步应该怎么走。
在还没有乾坤、模块联邦的时候，自己写过类似模块联邦的实现方式，也使用过iframe单例，后来又实用模块联邦、乾坤，都遇到一些业务无法解决的问题。
- js隔离其实还好，现在通过构建方式基本都能解决，比较头疼是css样式覆盖问题，特备是使用第三方库的时候，并不是所有的样式都使用了，css module、css in js这类方式，可能为了方便拓展，不然样式覆盖重写也比较头疼；
- 集成，这其实感觉还好，就是加载文件--渲染，在我们早起是每个子应用把渲染方法都挂在到一个window对象上，需要就直接调用。有点类似jQuery插件的方式；
- 通讯上实现上也是各种都尝试过，不过脱离不了“监听广播”的方式。
- 路由问题，如果加上保活这需求，目前还没找到好的方案，之前用乾坤，发现在子应用之间切换时是无法保活的(或许自己保存样子页面实例可以)；
- 模块联邦，本质上应该和npm包的方式是一致的，只是模块联邦转到了线上，让包和应用进行了解耦。
- Monorepo方式也了解过，感觉仓库管理都让人头大
这些应用也都在线上跑着，目前“路由+保活”这个方式好像都没解决，遇到最多的就是“公共样式”带来的问题，一步步走过来，样式各种覆盖。如果是全新项目，前期有约定好获取会好很多，但是大家的项目都是有简单到复杂，再拆分集成的。如果一开始就是用乾坤、wujie这种标准框架，或许问题会少很多（借用umi的一句话：约定大于配置）。另外跨部门也是大问题，技术难以统一，都是在各种兼容改造的路上前行。感觉最大的问题还是“统一管理”的问题，实现方式总是各式各样的。
做无界微前端的时候，当时最大的出发点是简化接入的成本，让业务在不理解微前端原理的前提下开箱即用。无界刚完成开发的时候，我们的低代码业务是第一个接入的项目，这个低代码业务代码非常庞大散落很多npm包，可以说几乎没有做任何修改就接入进来了，换成其他微前端框架有点不能想象，第一次被自己做的工具给爽到。
无界大量利用webcomponent和iframe这样的原生能力，在隔离度和易用性方面有很大的提升，但是从目前实践来看，微前端还是没有银弹。
要让webcomponent和iframe连接起来需要做代理工作，而很多属性的代理是矛盾的比如：popperjs希望元素的ownerDocument不要被劫持，这样弹窗冒泡就可以准确的计算位置不至于偏移，而兼容react17以下事件代理丢失需要劫持ownerDocument到iframe的document，有些库会从element.ownerDocument.defaultView中获取window所以也要劫持，所以框架层面只能劫持而很多组件的弹窗位置就不对也没办法解决了；我想实现一个空白的和主应用同源的iframe目前都还是无法实现；iframe销毁之后点击浏览器回退是没有办法做路由同步。
最终我发现了一个真理：没有微前端可以做到问题收敛，层出不穷的问题根源在于官方没有提供完美的沙箱。要接入微前端就必须要明白微前端内部运行原理以便有坑的时候不至于束手无策，这极大的提高了使用微前端的门槛，和我当初的预想偏离的越来越远。
我看国外的开发者似乎就没有开源出什么微前端框架，除了一个single-spa，非常明智的选择。我觉得在官方没有提供完美沙箱之前技术不应该做这个缝合怪，让很多产品层面需要解决的问题都丢给技术用微前端来解决导致微前端泛滥。
无界未来怎么规划呢？无界有两个方向可以做： 1、将更底层的能力暴露出来，所有使用上的问题开发自行通过修改无界底层能力来解决，框架作者只对底层能力负责 2、框架层面去兼容所有的case，目前来看已经不现实了
所以只有第一条路可选，但是这样的话就对开发者有很高的要求了，目前开发者其实也可以自行fork一份进行魔改来实现。而现实是大量的开发者还在询问跨域怎么解决...，开发者还是需要一套完整的方案，不想去关心微前端里面庞大的细节。矛盾已经不可调和，作为框架开发者也没有什么办法可以解决。
后续如果没有更好的沙箱出现，无界可能不做大的迭代更新了，大家也可以讨论一下无界下一步应该怎么走。
那能否接受一些处理现有问题的，比较好的解决方法的pr呢。让大家在这wujie这一公共基础上共享一些所谓“魔改”的成果
目前来说，微前端还是存在很多问题。无论是哪种方案，乾坤，无界，都是一样。
外部人员如果并不熟悉微前端框架，要使用得非常谨慎，后续排坑的代价并不小。
分享一下目前我们使用的方案，纯 iframe 实现。js 隔离，样式隔离都是内置的。但 iframe 同样面对一些问题，例如弹窗，并不是基座的 Document
为了解决这类问题，由基座提供 sdk，提供一些列的方法进行弹窗/通知（通过 postmessage 进行通信），然后子应用导入进行使用。至于如何保活等，由基座提供功能，子应用不用关心。
这样做起来不像所谓的 “微前端”，而更像 “微应用”。
对于子应用的开发者来说，心智负担大大降低，只需要关注 sdk 提供什么方法即可。
目前来说，运行良好，唯一的缺陷就是，通信方式使用 postmessage，序列化方式参考了 @electron/remote，所有 sdk 的操作，都是异步的
@axetroy 新支持了广播，某些场景应该可以代替 iframe postMessage， https://developer.mozilla.org/zh-CN/docs/Web/API/Broadcast_Channel_API
目前来说，微前端还是存在很多问题。无论是哪种方案，乾坤，无界，都是一样。
外部人员如果并不熟悉微前端框架，要使用得非常谨慎，后续排坑的代价并不小。
分享一下目前我们使用的方案，纯 iframe 实现。js 隔离，样式隔离都是内置的。但 iframe 同样面对一些问题，例如弹窗，并不是基座的 Document
为了解决这类问题，由基座提供 sdk，提供一些列的方法进行弹窗/通知（通过 postmessage 进行通信），然后子应用导入进行使用。至于如何保活等，由基座提供功能，子应用不用关心。
这样做起来不像所谓的 “微前端”，而更像 “微应用”。
对于子应用的开发者来说，心智负担大大降低，只需要关注 sdk 提供什么方法即可。
目前来说，运行良好，唯一的缺陷就是，通信方式使用 postmessage，序列化方式参考了
@electron/remote，所有 sdk 的操作，都是异步的
sdk可以开源出来吗？
@axetroy 为什么不考虑把postMessage用google的comlink包一下, 当作一位async function使用呢?
在做这个的时候，我并不知道 comlink，所以就自己实现了一个。区别无非就是，换个皮肤而已
- const result = await sdk.invoke('sum', 1, 2)
+ const result = await sdk.sum(1, 2)
