乾坤 微前端_再谈微前端

前言

我们的业务主要是做一些中后台的前端项目，有两个特点：生命周期长、代码量庞大，这带来了技术栈落后、编译部署慢两个问题。虽然我们之前在编译缓存上做了些努力，但是治标不治本，在项目极大的情况下编译时间还是不够理想。因此，微前端应该是唯一的解决方案了。

于是我们做了一些微前端的技术调研，主要是乾坤和single-spa这两个框架，一开始我们觉得基于single-spa的乾坤应该会比single-spa本身更符合我们的需求，但是经过深入探索后，发现情况远没有我们想象的那么简单。

两种微前端

在做了一些调研后，有个问题一直困扰着我：微前端到底是什么？

乾坤

在乾坤的角度，微前端就是“微应用加载器”，它主要解决的是：如何安全、快速的把多个分散的项目集中起来的问题，这从乾坤自身提点便可看出：

所有这些特性都是服务于“微应用加载器”这个定位。

single-spa

在single-spa的角度，微前端就是“微模块加载器”，它主要解决的是：如何实现前端的“微服务化”，从而让应用、组件、逻辑都成为可共享的微服务，这从single-spa关于微前端的概述中可以看出：

在single-spa看来微前端有三种类型：微应用、微组件、微模块，实际上single-spa要求它们都以SystemJS的形式打包，换句话说它们本质上都是微模块。

SystemJS是一个运行时加载模块的工具，是现阶段下(浏览器尚未正式支持importMap)原生ES Module的完全替代品，在此不做过多介绍，更多内容请看： https:// zh-hans.single-spa.js.org /docs/recommended-setup#systemjs

谁才是微前端？

要讨论这个问题，我们要先想清楚以下两点的区别：

1. 微应用加载器：“微”的粒度是应