微前端方案对比

目前较成熟的微前方案有 qiankun、micro-app、EMP 方案，下面分别分析这三个微前端方案：

qiankun 方案

qiankun 方案是基于 single-spa 的微前端方案。

特点

1. html entry 的方式引入子应用，相比 js entry 极大的降低了应用改造的成本；
2. 完备的沙箱方案，js 沙箱做了 SnapshotSandbox、LegacySandbox、ProxySandbox 三套渐进增强方案，css 沙箱做了 strictStyleIsolation、experimentalStyleIsolation 两套适用不同场景的方案；
3. 做了静态资源预加载能力；

不足

1. 适配成本比较高，工程化、生命周期、静态资源路径、路由等都要做一系列的适配工作；
2. css 沙箱采用严格隔离会有各种问题，js 沙箱在某些场景下执行性能下降严重；
3. 无法同时激活多个子应用，也不支持子应用保活；
4. 无法支持 vite 等 esmodule 脚本运行；

micro-app 方案

micro-app 是基于 webcomponent + qiankun sandbox 的微前端方案。

特点

1. 使用 webcomponet 加载子应用相比 single-spa 这种注册监听方案更加优雅；
2. 复用经过大量项目验证过 qiankun 的沙箱机制也使得框架更加可靠；
3. 组件式的 api 更加符合使用习惯，支持子应用保活；
4. 降低子应用改造的成本，提供静态资源预加载能力；

不足

1. 接入成本较 qiankun 有所降低，但是路由依然存在依赖；
2. 多应用激活后无法保持各子应用的路由状态，刷新后全部丢失；
3. css 沙箱依然无法绝对的隔离，js 沙箱做全局变量查找缓存，性能有所优化；
4. 支持 vite 运行，但必须使用 plugin 改造子应用，且 js 代码没办法做沙箱隔离；
5. 对于不支持 webcompnent 的浏览器没有做降级处理；

EMP 方案

EMP 方案是基于 webpack 5 module federation 的微前端方案。

特点

1. webpack 联邦编译可以保证所有子应用依赖解耦；
2. 应用间去中心化的调用、共享模块；
3. 模块远程 ts 支持；

不足

1. 对 webpack 5 强依赖，老旧项目不友好；
2. 没有有效的 css 沙箱和 js 沙箱，需要靠用户自觉；
3. 子应用保活、多应用激活无法实现；
4. 文档上也没有看出对主、子路由怎么做合并处理；

结论 qiankun 方案对 single-spa 微前端方案做了较大的提升同时也遗留下来了不少问题长时间没有解决； micro-app 方案对 qiankun 方案做了较多提升但基于 qiankun 的沙箱也相应会继承其存在的问题； EMP 方案基于 webpack 5 联邦编译则约束了其使用范围； 目前的微前端方案在用户的核心诉求上都没有很好的满足，有很大的优化提升空间。

无界方案

无界微前端方案基于 webcomponent 容器 + iframe 沙箱，能够完善的解决适配成本、样式隔离、运行性能、页面白屏、子应用通信、子应用保活、多应用激活、vite 框架支持、应用共享等用户的核心诉求。