微前端的现状以及趋势 _前端

这些公司使用微前端的具体方式各不相同，不过，使用微前端的意图大同小异。
使用微前端的公司
（上图来自 Luca ）
这个列表每天都在增长，从、HLC 这样的咨询公司到、这样的 SaaS 提供商。但是很多传统的公司也开始押注微前端。德国的隐形冠军霍夫曼集团就是其中的一个例子。
霍夫曼集团是一个很好的例子，微前端不需要非常大的团队，也不需要公司内部的资源。霍夫曼集团选择微前端的原因正是因为它们要和多个服务提供商打交道。
微前端组件的例子
Bit.dev 平台和营销网站都是基于 React 组件构建，管理 React 组件是通过……Bit 。
看看它们的页面。悬停在不同组件上会显示这些组件原本属于哪个组件集。点击组件名可以查看组件，甚至在你的项目中加入这一组件。
Bit.dev 截屏
这个页面是通过两个组件集中的组件构建的，这两个组件集对应上两个不同的代码仓库，base-ui (Bit.dev 页面) 和。
base-ui 和的 Bit.dev 页面
base-ui 组件集起到了设计系统的作用。组件集中的组件（用于营销页面）使用了 base-ui 中的一些组件，以便在不同的微前端上保持统一的风格。
在这个例子中，Bit 既用于实现自主交付，也用于保持不同微前端的界面一致。
如何构建微前端
很不幸，这个有趣的问题只有一个含混的答案：就像微服务一样，并不存在适用于所有人的单一方法，也没有业界标准。
不同于微服务，微前端引入了基本性的差异，而不仅仅是实现细节上的差异。所以，我们需要区分微前端的使用范围。一些服务端框架也允许客户端复合（-side ），不过，相反的情况也是成立的。
客户端框架

文章插图
客户端微前端框架有很多，有些也同时支持服务端渲染。
客户端复合
以下框架实现了微前端模式（或类似微前端的模式）：
Piral
Open
【微前端的现状以及趋势】Luigi
Frint.js
服务端框架
服务端微前端框架也不少。有些不过是基于的库或框架，但另一些框架则需要依托于你的基础设施。
服务端复合
以下框架实现了微前端模式（或类似微前端的模式）：
辅助库
还有一些辅助库提供了一些基础设施，例如共用依赖、路由事件、组合不同的微前端及其生命周期。

文章插图
下面是一个处理共用依赖的例子，利用了maps、chunk （内部使用的一个概念）之类的机制。
基于maps 共用依赖
下面这些库有助于减少模板代码：
SPA
.js
微前端调研
我希望以后基于社区数据重新梳理一下这部分的内容。但我需要你们帮忙提供数据。
我用谷歌表单做了一份简单的调查表，应该能在 5 分钟之内填完。请帮忙扩散（比如通过）。非常感谢！
调查到八月底截止，九月初会发表结果。
微前端的下一步
尽管有些人觉得微前端会集体转向模块聚合（）之类的辅助库，大多数人仍将使用自研解决方案。好消息是在许多框架下很容易编写避开强供应商锁定的代码。不管怎么说，微前端缺少一个公共标准，方便在技术层面交换解决方案。
另外，目前微前端仍未被社区广泛接受和采用。
尽管微前端模式变得流行，社区中仍有很多人心存疑虑。
有一个原因是微服务并没有被视为面向特定场景的另一个工具，而是被视为设计后端时的一种最佳实践和标准。显然微服务不应该这么用。因此，微前端也不应该被视为银弹。