为什么会有 rxjs 这种库？

[yhvictor]

别人推荐我看一下 reactiveX，于是看了下，一看 operator 真是不知道多少个： https://www.learnrxjs.io/operators/

相比较之下，guava concurrency 的 operator 就少得多了（一半以上还是因为重载）： https://google.github.io/guava/releases/21.0/api/docs/com/google/common/util/concurrent/Futures.html

所以，rxjs 这东西有什么好处呢？为什么能火呢？ 以及 javascript 有没有类似 listenable future 的类或者库呢？

[Perry]

rxjs 主要靠 Angular 壮大起来的，目前来说还不算火吧。。。

[ljzxloaf]

rxjs 不知道,rxjava 就是一种开发范式.由事件和数据驱动业务逻辑,将业务解耦得比较彻底,适合复杂多变的业务场景,当业务发生变化时,改动比较小-------以上是官话.

我没用过只看过别人的例子,我的理解是简单项目尤其是现在大家都是微服务了,真的用不上这个,如果要用的话也不会直接用,应该结合各自的业务场景再封装一遍,否则开发效率可能要大打折扣.东西是好东西,但是没必要全盘接收.缺点是代码的可读性变差,当然整体上来说更易于理解,逻辑也更清晰了,但是局部代码因为变成了通用逻辑,读起来没那么直观.还有个重要的缺点是调试起来更麻烦了,如果不熟悉的人可能搞不懂它的执行流程.还有涉及到并发 /异步 io/流控什么的时候容易用错. 如果没有接触过这些概念的话有一定的学习成本.

另外,用不用是一回事,了解一下思想还是有好处的.我就是了解了一下,这不是就装了个 X(

[ChefIsAwesome]

假设你需要抓 100 个页面，考虑到性能，你的策略是这样的：
每 5 个页面为一组，因为异步的特性，5 个请求可以同时进行。这 5 个请求完成的时间未知（第 5 个可能在第一个之前完成），你希望收集到数据仍然是按顺序排列的。
一组请求全部完成之后才进行下一组，直到全部完成。

这已经是个相当复杂的过程了。实际场景可能更复杂：
一个请求失败时，自动重试，最多可以试 3 次。
一组操作完成之后，等 3 秒钟才进行下一组。

用 rx 的话，上面描述的问题就非常容易解决。
简单讲，observable 是高级的 promise。当你把异步操作封装成一个可以组合，可以被函数返回的值的时候，很多问题都可以迎刃而解了。
前端应该碰不到这么复杂的异步问题，好多人看的云里雾里，所以没那么火。

[gzf6]

就是异步的一种处理方式，也可以用别的方式，不必拘泥于一种

[sagaxu]

@ChefIsAwesome 这个例子用 Future 组合写起来也不复杂，用协程就更简单了吧，直接写循环，跟同步阻塞代码一样写。

[lhx2008]

好像还有 reactorjs，也是 rxjava 那班人写的

[ooeyunarika]

reactiveX 这套异步处理思路现在主流语言都有对应的类库,在处理异步问题上得到相同的体验,学会一套就到处受用了,多少会降低一些跨语言异步处理的心智负担

相比于其他语言尤其是 java,js 的异步处理工具和类库要丰富和成熟很多,所以 rxjs 确实在这当中不算突出,但如楼上大佬们所说,rx 这套工具衍生自 linq,是大量地开发实践后催生出来的更为成熟的异步处理思路.

至于可读性降低那只是因为异步本身就需要考虑那么多复杂的场景,只是之前大部分都被忽略了.尤其是前端,以前大部分用 promise 都只考虑 success 而忽视了 failure 的处理,在前端最多控制台报个错用户刷新一下就恢复了,放在后端就可能是非常致命的 bug.

[asAnotherJack]

rxjava 挺火的

[xzk715]

说 rx 主要是位了解决异步问题的 一看就不是真了解 rx

[Sapp]

rx 其实我是用来做一些数据处理，如果真的数据非常多，非常乱，需要几路并流，然后经过转换输出结果，还是好用的，其他业务没什么必要，不过我还是经常用 xstream，比 rxjs 小，更简单，偶尔用用也够用了