国外微前端的不同流派 ​

诚然这和merak无关，但我认为值得一说。

至少在这个项目开发初期，我都是对标着国内主流微前端方案做的，

无非是轻量一点，舍弃维护困难的部分，积极拥抱esm，

但国外微前端的一些想法，倒是让这个项目有一些不一样的能力了

国外微前端大约有四类

template ​

这是最简单的一种，也就是不管不顾，把子应用的html拼进主应用对应位置

等同于将几个字符串拼接起来

当然，不同的库手法不同， 有的是使用web component 去拼， 有的在主页面专门留一个内容区，主应用只负责侧边栏等部分 有的则在服务端拼 有的干脆在网关处拼

然后再提供一些小功能，就差不多了

这种模式虽简单到近乎简陋，但却有一个优势：这是唯一一个可能支持SSR的模式

lifecycle ​

为什么说前一类方式简单？因为其对于js的影响装聋作哑--它根本就没有考虑js这个东西！

如果子应用监听了个事件，那么主应用将毫无办法

只能寄希望于挂载多个子应用后，内存仍未爆炸--这显然是不可能的

真实的需求是，需要子应用的时候去加载，不需要的时候再移除

single-spa首先做出努力：将子应用暴露出三个钩子,不管子应用是什么框架，用什么写法，我只负责在初始化、挂载、卸载时执行钩子，

至于怎么初始化，怎么挂载，那是你自己的事

single-spa同样也很简单，故而其团队把更多的精力放在了生态上，导致相关的包奇多,反而看着不那么简单了

国内的微前端基本是延续这个思路，只不过做的更完善，提供了更多托底的能力

不能说这样不好，实际上这样对维护水平要求很高--你必须要用各种hacker手法去造出"iframe"，在有限的代码里处理掉无限的边界情况

federaion ​

single-spa的团队比较倾向in browser,也就是所有功能尽量利用浏览器原生功能实现

这样一个显而易见的好处是，项目很难出现完全迷糊的问题--毕竟没有webpack了是吧

但麻烦的是，浏览器原生压根就没有模块加载功能（至少其兼容度完全不行），所以single-spa主推systemjs，案例都是绑定来讲

我们很难去这么学，webpack是必须要处理的一个环节

那在webpack情况下，很多事情就变得很糟糕了,依赖共享、版本控制、功能导出...一些功能还能自己写插件解决，但webpack内置的模块加载方案可不是 systemjs那般讲道理的：一个应用的chunk,挂载到浏览器上就会去找webpack的全局变量报道，但微前端中，主应用加载子应用，子应用的chunk压根就没法找到这个全局变量（因为每个应用全局变量名不一样）...你再着急也只能干瞪眼

webpack官方在4-5的过程调整了架构，既然社区没法搞，俺就留个后门帮帮你们，然后推出了模块联邦这个插件

可以看到，其实模块联邦这个插件并没有提供什么不得了的能力，它只是把打包器带来的麻烦抹平了而已，

实际上，你只要不用webpack一样可以抹平麻烦，这个插件其实什么也没办到 奇葩的是，这个模块联邦的实现反而变成了一种标准，本身就有原生模块加载的vite等反而倒过来去追求模块联邦，有一点本末倒置的味道了

简言之，federaion 对应着在打包器中的微前端管理，主打依赖共享等功能，但webpack的模块联邦插件我认为还差着一节

社区中围绕模块联邦提供一大堆插件，这些东西很棒，他们真的提供了新的功能，如果算上这些，那么webpack的模块联邦是一个不错的federation方案 但如果使用federation要引入这么一大堆东西，其实还是要再想想的

module ​

这种我只知道一个:piral 它的意思是这样的：一个模块并不唯一对应一个视图

比如我有个用户模块，那么侧边栏可能跟这个有关，登录页也有可能，一个模块就对应多处视图

在piral中，子应用并不再是主应用的一个单一视图部分，而是一个真正的部分，

子应用可以提供侧边栏+表单+顶部栏+鉴权...子应用可以干更多事情

应该有团队在用类似的东西，不过大多都是自用，名声不显

最大的原因就是，我们希望微前端方案能将现有的、可能编译器不同框架不同写法不同的项目连起来，而这种方案强迫所有应用使用统一编译器，统一规范，基本就等于从头开始了，只有起步的团队会考虑

这种模式在微前端不常见，但在低代码领域却有一席之地，因为低代码项目都是自定一套标准，围绕着标准开发，统一的模式反而让module有用武之地