转自团队掘金原文:https://juejin.cn/post/6898268972178178061
在之前的文章中,我们已经深入剖析了微前端究竟是什么,可以带来什么收益,现在让我们复习一下微前端的概念:
Techniques, strategies and recipes for building a modern web app with multiple teams that can ship features independently.
中文释义:
可以由多个团队独立开发的现代web应用程序的技术、策略和方案。
本文则是在此基础上对现有的微前端解决方案进行对比总结,废话少说,让我们开始今天的课题。
查找了大量的资料后,我总结了以下主流的能够真正实现微前端概念的解决方案,如有遗漏,欢迎小伙伴们补充~
1、iframe
众所周知,iframe
是html
提供的标签,能加载其他web应用的内容,并且它能兼容所有的浏览器,因此,你可以用它来加载任何你想要加载的web应用。
iframe最大的特性就是提供了浏览器原生的硬隔离方案,不论是样式隔离、js 隔离这类问题统统都能被完美解决。读到这时,相信小伙伴们跟我一样,觉得iframe与微前端概念中提到的独立开发
、独立维护
、相互隔离
非常的吻合,有种直接上ifame就完事儿了的想法,但为何它到现在也不是微前端主要的实现方式呢,后来有幸拜读了qiankun技术圆桌
中一篇关于微前端Why Not Iframe的思考,总结的很到位,现复述其中的一段描述
iframe虽然基本能做到微前端所要做的所有事情,但它的最大问题也在于他的隔离性无法被突破,导致应用间上下文无法被共享,随之带来开发体验、产品体验的问题。
以下是我对该文中总结部分的总结:
经过以上思考,我个人也有了一些拓展总结:
我猜,以上原因便是iframe
没能作为官方微前端方案的原因吧。
2、Web Components
或许很多小伙伴对Web Components
不是很了解,它是由google
推出的浏览器的原生组件,MDN
对Web Components的定义是这样的:
作为开发者,我们都知道尽可能多的重用代码是一个好主意。这对于自定义标记结构来说通常不是那么容易 — 想想复杂的HTML(以及相关的样式和脚本),有时您不得不写代码来呈现自定义UI控件,并且如果您不小心的话,多次使用它们会使您的页面变得一团糟。
Web Components旨在解决这些问题 — 它由三项主要技术组成,它们可以一起使用来创建封装功能的定制元素,可以在你喜欢的任何地方重用,不必担心代码冲突。
它的三项主要技术是指:
和
元素使您可以编写不在呈现页面中显示的标记模板。然后它们可以作为自定义元素结构的基础被多次重用。通过以上描述,再结合微前端的概念,我们来看看Web Components
是如何做到微前端:
Web Components
是浏览器原生组件,那即是在任何框架中都可以使用。Web Components
开发的应用无需与其他应用间产生任何关联。Shadow DOM
的特性,各个引入的微应用间可以达到相互隔离的效果。综上所述,Web Components
是有能力以组件加载的方式将微应用整合在一起作为微前端的一种手段,但不幸的是,Web Components
是浏览器的新特性,所以它的兼容性不是很好,如果有兼容性要求的项目还是无法使用,具体请查看can i use。
3、ESM
ESM
是ES Module
的缩写,是Ecma script 2015
中提出的一种前端模块化手段,那么,它又是如何做到微前端的呢?其实,微前端无外乎三大特性,无技术栈限制
、应用单独开发
,多应用整合
,只要抓住了这三个特性,那就不难理解ESM
如何做的了:
ESM
加载的只是js内容,无论哪个框架,最终都要编译成js,因此,无论哪种框架,ESM
都能加载。ESM
的方式暴露出来,就能正常加载。ESM
能够直接请求cdn
资源,这是它与生俱来的能力。ESM
是能做到微前端的核心思想,但是它也存在着兼容性这一大弊端,尽管ESM
已经很优秀了,但是大部分老版的浏览器仍然无法直接使用,这也是babel等编译工具出现的原因,幸运的是,他可以通过webpack
、rollup
、esbuild
、snowpack
等编译工具成为兼容性的代码。
4、qiankun
在微前端界,qiankun
算得上是最早成型且知名度最广的框架了,它是真正意义上的单页微前端框架,那么qiankun
到底有哪些特点呢,在其官网中我找到了如下概括:
single-spa
封装,提供了更加开箱即用的 API5、EMP
EMP是由欢聚时代业务中台自主研发的最年轻的单页微前端解决方案 那么,他有哪些特性呢,下面我们一起看看:
Webpack5
的新特性Module Federation
实现,达到第三方依赖共享,减少不必要的代码引入的目的,什么是Module Federation这里就不再赘述。Module Federation
的应用使用。并且此部分代码是远程引入,无需参与应用的打包。EMP
是通过cdn
加载微应用,因此每个微应用中的代码有变动时,无需重新打包发布新的整合应用便能加载到最新的微应用。cerate-react-app
一样,也能像create-vue-app
一样,通过指令一键搭建好开发环境,减少开发者的负担。emp-cli
中内置了拉取远程应用中代码声明文件的能力,让使用ts开发的开发者不再为代码报错而烦恼。细心的小伙伴应该发现,EMP
除了具备微前端的能力外,还实现了跨应用状态共享、跨框架组件调用的能力,这是现有框架所不具备的优秀特性!
又到了下课的最后五分钟时间,一起来看看今天的分享都有哪些关键的知识需要掌握:
iframe
可以直接加载其他应用,但无法做到单页导致许多功能无法正常在主应用中展示。
web Components
及ESM
是浏览器提供给开发者的能力,能在单页中实现微前端,不过后者需要做好代码隔离,并且他们都是浏览器的新特性,都存在兼容性问题,微前端方面的探索也不成熟,只能作为面向未来的微前端手段。
qiankun
基本上可以称为单页版的iframe,具有沙箱隔离及资源预加载的特点,几乎无可挑剔。但可能存在以下几点不足:
EMP
作为最年轻微前端解决方案,也是吸收了许多web优秀特性才诞生的,它在实现微前端的基础上,扩充了跨应用状态共享、跨框架组件调用、远程拉取ts声明文件、动态更新微应用等能力。同时,细心的小伙伴应该已经发现,EMP
能做到第三方依赖的共享,使代码尽可能地重复利用,减少加载的内容。
以下表格为各解决方案的总结:
解决方案 | 相对特点 | 缺点 |
---|---|---|
iframe | 天生隔离样式与脚本、多页 | 不是单页应用,会导致浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用 |
弹框类的功能无法应用到整个大应用中,只能在对应的窗口内展示 | ||
由于可能应用间不是在相同的域内,主应用的 cookie 要透传到根域名都不同的子应用中才能实现免登录效果 | ||
每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程,占用大量资源的同时也在极大地消耗资源 | ||
iframe的特性导致搜索引擎无法获取到其中的内容,进而无法实现应用的seo | ||
Web Components | 天生隔离样式与脚本 | 无法兼容所有浏览器 |
ESM | 远程加载模块 | 无法兼容所有浏览器(但可以通过编译工具解决) |
需手动隔离样式(可通过css module解决) | ||
qiankun | HTML Entry 接入方式 | - |
资源预加载 | ||
EMP | 每个微应用独立部署运行 | - |
动态更新微应用 | ||
去中心化 | ||
跨技术栈组件式调用 | ||
按需加载 | ||
应用间通信 | ||
生成对应技术栈模板 | ||
远程拉取ts声明文件 |
分享到此结束,对EMP微前端方案感兴趣的话,可以从这里学习到更多内容:
基础知识解析
什么是微前端
对比多种微前端方案
webpack5 module Federation原理学习
EMP的设计架构
快速入门
react项目如何使用和接入EMP
vue项目如何使用和接入EMP
辅助插件的使用教程
进阶教程
Vue和React项目如何互相远程调用
cocos2d 项目如何使用和接入EMP
教你基站搭建技巧