通过微前端向下发送冗余代码

我对微前端的理解是，他们解决的关键问题是帮助企业拥有多个可能组成不同的团队，研究将用于组成大型Web应用程序的单个组件/小型应用程序。

这里要解决的关键问题是多个团队独立工作的能力，并且仍然能够构建大型复合材料。问题不在于为最终用户提供精简的发行包。这种理解正确吗？

的确，如果我们有多个用于组成大型Web应用程序的小型应用程序，则有可能会有多个小型应用程序将相同的Javascript库（例如Lodash）作为最终用户的一部分传送给最终用户的浏览器。各个供应商捆绑包是否导致一定数量的重复/冗余代码被发送给用户？

在设计前端应用程序时，这不是我们应该担心的问题吗？

您绝对正确，这里涉及到一个折衷方案：您在用户体验的某些方面进行权衡以获得更好的开发人员体验（这反过来可能以不同的方式改善用户体验）。这值得吗？这取决于。

例如，我认为Spotify使用这种方法将其UI拆分为隔离的组件（源）。每个小部件都位于一个iframe中，因此可以拥有自己的一组库等。它们具有独特的组织约束，即工作由自主小组（跨职能团队）执行。这使得在公司范围内的标准上达成一致并随后更改这些标准变得更加困难。因此，对于他们来说，微前端有助于保留一定的灵活性。但是如果没有这种方法，那么他们的桌面应用程序可能会减少内存消耗。

HTTP缓存无济于事：每个微前端可能使用不同的框架版本。此外，复制的成本不仅是数据传输，还包括客户端（重新）编译库和存储重复的数据结构的成本。

就我个人而言，我认为这样的微前端可能是有效的架构，但除非有可能，否则不建议使用

• 您是一个非常庞大的组织，拥有高度自治的团队，他们都在用户界面上工作，并且需要非常频繁地发布（例如每天），并且
• 您的UX性能预算有足够的空间进行此复制，或者您的产品质量很好，以至于UX都无关紧要。请注意，应该在低端设备（而不是开发计算机）上测试性能。

如果您的组织规模不大，或者您的团队更加专业化，那么每个参与人员（管理人员，开发人员以及最终用户）都可以拥有一个通用的构建和部署流程，从而避免不必要的重复。例如，如果您只有4个团队在UI上工作，那么他们可能可以互相交谈以就一组通用的库达成共识，以及如何将他们的工作集成到一个紧密的体系结构中。

微前端似乎是其中的一件很酷的事情，但是只有在大规模运行之后，您才真正需要微前端。