跟 qiankun 比起来有哪些优缺点

[Amorites]

这应该是大多数人的第一反应

[highestop]

+1

略读了一遍介绍，第一反应是『 作为第三方用户为什么不选择 qiankun 而是选择 garfish 』。目前社区中的微前端方案也不少，希望了解一些横评和对比分析，感觉头条在内部启动这个项目的时候应该已经做了不少这方面的分析了

[fuyunzhishang]

同问

[JessYan0913]

garfish有提供react_in_vue和vue_in_react的方案
读：https://jishuin.proginn.com/p/763bfbd62a62

[ac51300696]

使用乾坤算比较多的来答一下，欢迎讨论

[ac51300696]

在使用乾坤的时候遇到了一个很明显的两个问题，一个是qiankun其实只是一个架子，比如不同应用之间的数据传输，事件模型，不同应用之间组件服用，如何灰度控制策略等都是提供一个可实现的方案，具体得自己完成。所以在我看来这些所有的微服务方案其实都是本质上是实现了在页面上在多个渲染节点上渲染单页应用。所以与其问有什么优缺点，还不如去选择使用webpack5实现微服务还是singlespa那一套方案。因为本质上后者可能更具有对比性

[ac51300696]

第二个遇到的问题就是性能问题，很可怕的性能问题，本质原因是沙盒和代理。这个问题具体的可以去qiankun issus里面看看相关的，基本没一个能解决的，我都怀疑是沙箱或者代理全局对象所带来的必要代价了。所以，微服务其实不是一个银弹，他没有解决任何具体问题，他只是提供给了你一个能力。从这个角度来看，其实用什么问题都不大。你反而可以认真考虑下这些框架团队的维护更新能力

[imtaotao]

性能问题更多的是动态作用域带来的，也就是 with 导致的。但是现在在运行时能处理作用域的也只有 with，garfish 将常用的标准函数提升为静态的变量，在性能方面缓解了很多。

意思就是garfish会性能好很多？

理论上是这样的

[yanni4night]

性能问题对于典型的PC巨石应用来说，应该不是首要问题，这一类应用往往承载得是复杂的管理系统、后台，不过分的性能损失是可接受的。但要分种类：

1. sandbox带来的性能损失，对于js来说，umd应该可以忽略不计，但esm因为有polyfill，要更重一些，甚至可以有逻辑漏洞，我认为不是非必要的话可以不使用；
2. entry解析html格式考量的是子应用的独立运行问题，但子应用export一个json格式并非难事，完全没有必要非要把html作为entry，这一部分损失是没必要的。

[renwofei423]

性能问题对于典型的PC巨石应用来说，应该不是首要问题，这一类应用往往承载得是复杂的管理系统、后台，不过分的性能损失是可接受的。但要分种类：

1. sandbox带来的性能损失，对于js来说，umd应该可以忽略不计，但esm因为有polyfill，要更重一些，甚至可以有逻辑漏洞，我认为不是非必要的话可以不使用；
2. entry解析html格式考量的是子应用的独立运行问题，但子应用export一个json格式并非难事，完全没有必要非要把html作为entry，这一部分损失是没必要的。

如果性能被折损了10-20倍，你就不会认为这不是首要问题了。。。

打个比方，之前使用qiankun，一个modal弹框需要3-5秒才能弹出来（正常可能只要0.3s甚至更低），你觉得无论领导还是客户能接受？

[yanni4night]

抬杠了，先抛开esm，如果仔细看过源码，应该知道只要实现sandbox，原理都是大同小异的，或者说没有区别，因此不可能有非常明显的性能差异，相比于原始代码的损失是差不多的。

当然非要比对esm下的sandbox，那是需要重新转译的，不是包一层with就可以了。

[NNNaix]

性能问题更多的是动态作用域带来的，也就是 with 导致的。但是现在在运行时能处理作用域的也只有 with，garfish 将常用的标准函数提升为静态的变量，在性能方面缓解了很多。

意思就是garfish会性能好很多？

理论上是这样的

qiankun 2.9.0 也亦步亦趋了

[ChangerHe]

粗看了一下API, 似乎与乾坤的api也是类似的, 期待官方能够从底层实现, benchmark等角度来对比一下差异