突然意识到，前端微应用也许是个伪需求

[aikilan]

最近基于 single-spa 拆分了日渐庞杂的一个前端工程，工程本身基于 vite 开发，子应用也全部使用 vite ，这中间大小坑多少也踩的差不多了，子应用的 hot reload/unmount/自动切换子应用的环境 /根据权限渲染子应用 /数据、权限、方法共享巴拉巴拉......

搞完以后，索然无味，突然意识到，这个改造的过程中，似乎终极目标就是让子应用的使用体验就像是写在同一个工程内一样，问题来了，既然终极目标就是写在同一个工程内，那么为什么一开始我要拆分呢？难道仅仅是为了一个概念上的“微前端”？？？

前端子应用的本质是为了追求独立部署（也许吧），但是在实际业务中，子应用很可能是一个看似独立实则业务与父应用高度耦合的模块，这就不可避免子应用调用父应用诸多业务实现，你很少有独立存在的必要（起码在我接触的业务中是这样的），这就意味着一旦子应用脱离了父应用的环境，你就需要为这些原本属于父应用的业务能力打补丁，这就显得很冗余。

如果父子应用都写在一个工程内，通过修改构建配置，实现独立打包 /部署，那么不但可以避免最开始那些需要踩的坑，还能轻松共享不同应用间的业务 /组件能力，所以诸如 single-spa 的出现，解决的是哪些真实业务场景需求呢？我很迷惑。当然了，搞技术的嘛，贵在折腾，于我个人而言，我还是有收获的。

最后，有折腾的机会我还是会去折腾的。

[hamsterbase]

组织架构决定软件架构。 微应用适合大公司，各个事业线一起开发同一个产品。 相互独立发布，不干扰。

[Hilong]

微应用还有一个用途, 同一个子应用可以被多个主应用引入, 可以做到灵活拼接业务.

[aikilan]

@throns 确实，不同技术栈杂糅在一起，十分令人不适。

[aikilan]

@libook
@hamsterbase
绝大部分公司的业务发展决定了技术架构的走向这点我十分认同，一家能纯粹靠技术推动业务的企业九牛一毛吧，有时候也会迷茫，绝大多数业务场景下，其实很入门的解决方案或者说技术栈就完全能够满足，但是对于一个技术人员来说，是不是需要主动的去做些什么，或者说“前瞻性”的去推动一些东西，其实说多了也是私心作祟。

[libook]

@aikilan 企业的目标是盈利，所以实际上都是需求驱动技术，反过来不符合企业发展的客观规律，除非是在研究机构，或是土豪公司愿意出钱养创新。

像微前端这种也是企业业务需求、经营成本需求、管理需求所催生出来的技术，是现阶段满足特定需求的最佳方案而已。

我个人认为，作为技术人员，首先要了解业务，然后才能根据业务需求精准得进行技术选型和技术设计。其次是做好技术雷达，了解新技术和行业案例，了解各项技术可以如何满足业务需求或者解决业务问题，从而在合适的时机可以被引入项目并被有效地利用。

在企业中工作，就要用企业一样的思维来思考。

[dudubaba]

那是你没做过 saas 化开发，特别是面向定制需求的。