无界还会更新吗，后续有什么迭代计划吗

[kakarote]

当前最新版本是v1.0.22，还是去年发布的，后续还会持续更新吗

[yiludege]

做无界微前端的时候，当时最大的出发点是简化接入的成本，让业务在不理解微前端原理的前提下开箱即用。无界刚完成开发的时候，我们的低代码业务是第一个接入的项目，这个低代码业务代码非常庞大散落很多npm包，可以说几乎没有做任何修改就接入进来了，换成其他微前端框架有点不能想象，第一次被自己做的工具给爽到。

无界大量利用webcomponent和iframe这样的原生能力，在隔离度和易用性方面有很大的提升，但是从目前实践来看，微前端还是没有银弹。

要让webcomponent和iframe连接起来需要做代理工作，而很多属性的代理是矛盾的比如：popperjs希望元素的ownerDocument不要被劫持，这样弹窗冒泡就可以准确的计算位置不至于偏移，而兼容react17以下事件代理丢失需要劫持ownerDocument到iframe的document，有些库会从element.ownerDocument.defaultView中获取window所以也要劫持，所以框架层面只能劫持而很多组件的弹窗位置就不对也没办法解决了；我想实现一个空白的和主应用同源的iframe目前都还是无法实现；iframe销毁之后点击浏览器回退是没有办法做路由同步。

最终我发现了一个真理：没有微前端可以做到问题收敛，层出不穷的问题根源在于官方没有提供完美的沙箱。要接入微前端就必须要明白微前端内部运行原理以便有坑的时候不至于束手无策，这极大的提高了使用微前端的门槛，和我当初的预想偏离的越来越远。

我看国外的开发者似乎就没有开源出什么微前端框架，除了一个single-spa，非常明智的选择。我觉得在官方没有提供完美沙箱之前技术不应该做这个缝合怪，让很多产品层面需要解决的问题都丢给技术用微前端来解决导致微前端泛滥。

无界未来怎么规划呢？无界有两个方向可以做：
1、将更底层的能力暴露出来，所有使用上的问题开发自行通过修改无界底层能力来解决，框架作者只对底层能力负责
2、框架层面去兼容所有的case，目前来看已经不现实了

所以只有第一条路可选，但是这样的话就对开发者有很高的要求了，目前开发者其实也可以自行fork一份进行魔改来实现。而现实是大量的开发者还在询问跨域怎么解决...，开发者还是需要一套完整的方案，不想去关心微前端里面庞大的细节。矛盾已经不可调和，作为框架开发者也没有什么办法可以解决。

后续如果没有更好的沙箱出现，无界可能不做大的迭代更新了，大家也可以讨论一下无界下一步应该怎么走。

[Tongzhongren]

o(￣▽￣)ｄ

[an501920078]

终于有一个正面回答还是很不错的，加油