微前端：技术选型

iframe

iframe有人造的隔离性，然而隔离性太强，导致以下问题：

1.刷新后iframe的url状态失落，无法控制iframe页面的后退后退；
2.想实现子利用免登录须要跨域共享cookie，反而导致安全性升高；
3.全局弹窗无奈实现
4.企业微信h5的iframe不反对跨域申请页面，详见这里

single-spa（文档地址）

性能上：

1.兼容多框架
2.html entry
3.加载和渲染原理：路由劫持，下载入口html，渲染到指标容器
4.不反对js隔离、款式隔离
5.不反对利用间通信
6.不反对预加载
7.没有思考微前端工程化和运维

社区活跃度 github star数量 11.3k、已解决issue数量 532（2022.6.27）
文档齐全，demo多

小结：

1.性能上，只做了路由劫持、提供参数填写加载微利用的逻辑。须要本人实现利用隔离、预加载和利用间通信。微前端运行时性能完整性 低。没有思考 微前端工程化 和 微前端运维 相干的性能。
2.老项目上，接入须要本人手写加载微利用的逻辑，且子利用须要额定装置依赖，接入成本高。须要本人实现利用隔离、通信、以及预加载等，更新成本高。
3.社区活跃度高，可维护性高；

qiankun（文档地址）

qiankun 是一个基于 single-spa 的微前端实现库，在 single-spa 的基础上进一步封装。

性能上：

1.基于single-spa欠缺以下性能：
a. 利用隔离

• js沙箱，依据Proxy的反对度以及是否多例，反对三种沙箱实现形式
• 款式隔离：反对shadow dom计划，以及试验式款式隔离
• 全局办法（setInterval、clearInterval、addEventListener、removeEventListener）劫持

b. 反对预加载
c. 基于props来实现父子通信

2.没有思考工程化问题：如专用依赖，组件复用

3.没有思考到微前端平台运维

社区活跃度：github star 数量 12.8k （2022.6.22）
文档齐全，demo多

emp

性能上：

1.思考了微前端的工程化问题，基于webapck5 MF性能解决公共依赖的问题，以及能够实现微组件共享。
2. 不反对款式隔离和js隔离
3.它的设计是去中心化，每个子利用都能够再接入子利用

社区活跃度：社区活跃度不高 star 1.8k （2022.6.22）
文档不欠缺

小结：

emp比拟适宜大型且处于立项初期时选用。须要事先做monorepo的布局、款式统一规划。

microapp（文档地址）

性能上：

1.摈弃了路由劫持的思路，选用类web component的计划
2.基于CustomElement和款式隔离、js隔离来实现微利用的加载，所以子利用无需改变就能够接入
3.反对利用隔离
4.通过劫持底层接口实现了元素隔离
5.提供了插件零碎
6.反对预加载
7.没有思考工程化问题：如专用依赖，组件复用
8.没有思考到微前端平台运维

这个框架基于CustomElement和Proxy API，前者针对低版本有polyfill，但后者没有，且目前官网文档说没有做兼容的打算
社区活跃度 star 2.7k（2022.6.22）
文档齐全

总结：

iframe、single-spa 在功能完善度上有余，所以放弃抉择；
emp 比拟适宜在我的项目初期选型应用，用约定来躲避款式隔离和js隔离（所以 emp 没有把利用隔离思考进去），比拟适宜在大型项目中应用；
microapp 和qiankun，性能残缺度上比拟好，只管 microapp 比 qiankun 多了元素隔离性能、插件零碎，且应用了类web component的思路升高子利用的接入老本。但基于 microapp 对 Proxy目前不思考兼容，且社区活跃度上，qiankun 更胜一筹，工期短须要有肯定的保障，所以最初选了qiankun