微前端的思考

[xmsz-stu]

用上微前端应该说好几年了... 各个框架实现原理大同小异，效果都差不多

现在刚好做个总结，我觉得微前端确实没多大意义...

我们从源头讲为什么有微前端，和名称一样，无非就是借鉴后端的做法，微服务呗。拆分服务、独立运行、独立维护都是特点，这个非常好啊
然后就有大聪明觉得，前端每个功能不也是单独服务吗？那不也可以参考后端微服务做法？嗯，想法是好的，但是忽略了很多东西。

比如说，其实独立运行实际上包含了 1. 不需要主应用就能运行 2. 其他服务可复用 两层含义。这两个含义在前端领域简直是毫无意义... 为什么？
你自己想想，什么情况下会有不需要主应用运行？没有主应用你的服务有P用？然后其他服务复用，同个应用里就主应用会复用.. 你想加在其他应用？这个场景也不现实，毕竟逻辑相同不代表界面相同...
这完完全全就是伪需求啊...

在90%的场景下，就是把模板变成独立应用，然后又只能100%依赖之前的主应用，简单说就是脱裤子放屁...

我们再来看看其他好处

1. 首屏打开快
   影响并不大，因为你拆的是应用又不是页面上的模块，两种毫无关系

2. 运行隔离
   这个也是蛮神经病的... 隔离它干什么啊？你是不信任你团队成员写的代码还是什么？还是你会引用别人的应用？
   这个功能就是炫技用的，就是理想化觉得我能做得到

...

还有更搞笑的，大部分项目就算拆了服务，也还是在同个monorepo里... 真的笑死

所以你看国际主流有用微前端吗？没有吧...

那应该这么做？

第一个就是忘记有微前端这种东西，真的很蠢...

第二个用其他方式解决你现有的需求

比如：

1. 你觉得项目代码太多了， 那就用monorepo方案在写代码的时候解决，非常有用
2. 你觉得构建速度太慢了，用懒加载、CDN、巴拉巴拉一些传统手动就能解决
3. 你觉得网页首次加载太慢了，用流式、用懒加载，很多方法都可以，效果特别好
   ...

你看到了吗？解决方向和微前端真的完全不同... 但是更合理啊
因为这些东西就应该在你写代码构建代码的时候解决，而不是在用户用的时候，你来加载个子应用...

[yiludege]

感觉你的的方案其实就是单页面应用(SPA)拆成多页面应用(MPA)，MPA要组合业务要不就是采用浏览器原生跳转要不就是iframe套着，面临子应用切换的体验差iframe弹窗问题，此时用微前端可以解决这些问题

还有特殊情况比如老系统或者其他部门的系统集成，这些系统要不就是没办法动要不就是没有权限动，性能也可能很糟糕，体验感就会更差，不采用微前端的话集成到现有系统会有明显的割裂感

但不可否认国内微前端是泛滥了，有开发的责任更有产品的责任，希望大家都用不上微前端吧 😄

[xmsz-stu]

这么看，也就是老项目(包含MPA多项目)会有需求... 所以微前端不应该是默认选项，默认应该是不搞，不动这种项目

[gaoyan1998]

还是有场景的，我们主项目是react的，但是有个vue项目要拿进来（别问vue项目哪里来的，就是有），重写代价太大了，也很没必要，微前端就很方便了

[gaoyan1998]

还是有场景的，我们主项目是react的，但是有个vue项目要拿进来（别问vue项目哪里来的，就是有），重写代价太大了，也很没必要，微前端就很方便了