RxJS 8: To observable or not to observable?

[benlesh]

Web platform Observables are on the horizon. Inclusion of web platform observables in Node is nearly a given, because they're part of EventTarget, which is in node.

RxJS 8 has been in alpha for a while, mostly because it's all volunteer work, and I've been spending a good amount of time working on the web platform observables, because it's very important.

I'm torn about whether to release a standalone RxJS Observable. Skip that and release a Web Platform polyfill observable, or something in the middle.

A Standalone RxJS Observable?

Part of the plan for RxJS 8 was to publish @rxjs/observable as a package, which would be a package that only included Observable and related, necessary types (Subscription, Subscriber, etc etc). That was always meant to be "The RxJS observable", complete with pipe() et al, just without any of the operators (map, filter, concatMap, etc).

This was in response mostly to library authors who wished for widely-known, battle-tested RxJS observables, but didn't want to ship something that included access to all of the operators (which is honestly where most people tie themselves in knots if they don't know what they're doing).

Web Platform Observable

As stated above, the web platform is adopting observables as a means to help developers compose events. Which is really how observables shine. This observable will ship with a pretty robust set of methods: map, filter, take, drop (skip), flatMap (concatMap), switchMap, scan, tap, catch (catchError), takeUntil, finally (finalize), first (firstValueFrom) and last (lastValueFrom), and Observable.from() (our from).

With the set of operations listed above, even yours truly will reach for RxJS less and less. And I couldn't be happier about that!*. RxJS will have become "lodash for events" in reality. As a beloved set utility functions that gets less and less useful as the platform advances.

RxJS MUST align with the platform

In the very long run, RxJS will stop publishing our own observables, and will migrate existing RxJS over to use the observables in the platform. RxJS 8 is already trying to head that direction, with the addition of the rx() function, the fact that our subscribe only takes one argument now (readying us to align with the web platform's subscribe, which has a second argument that takes a configuration which includes an AbortSignal for cancellation).

Eventually, the RxJS codebase itself will be looking to see if what has been provided to any given operator is a platform observable or not, and relying on Observable being polyfilled globally.

How Shall RxJS 8 move to beta?

RxJS 8 is bringing a LOT of value already. It's about 30% smaller than RxJS 7 (which itself was 45% smaller than RxJS 6). It's faster and lighter, and at least starting to prepare us for a world where Observable is ubiquitously available in global scope.

However, finding time to get the work done is always a challenge. I know that if I cut RxJS 8, and wait until RxJS 9 to support web platform observables, it might take quite a while, and I'll have done at least some work I'll have to throw away. So I'm left wondering:

Do we proceed with releasing a standalone version of RxJS observables (pipe method and all?) knowing that they're fundamentally different than the web platform observables that will be available very soon?

Do we nix that idea, and instead release a standalone version of the Web Platform Observable, migrating RxJS itself over to this new era (and trying to do so in a way that breaks the fewest things? (i.e. supporting Subscription and AbortSignal for a short time, etc). This would also involve making sure that RxJS observable had all of the methods that the web platform observable does, and deprecated pipe, which will not exist on the platform observable.

Do we do something in the middle?

Other Considerations

1. Angular is no longer relying on RxJS for its libraries, or at least that's a goal of theirs. And I would recommend they use the platform observables when they're available if they want observables.
2. RxJS 7 is very stable, people seem happy with it, and there haven't been any huge glaring bugs outside of some quirks with our aging scheduler design, which is due for a revamp, but orthogonal to observables themselves.
3. There's not a pressing need to go to beta right now, other than it's been a long time.

[Jordan-Hall]

I would love to see RxJS's next move involve becoming a polyfill for the Web Platform's Observable, and rxjs then adding extra functionality similar to Lodash. The work done on version 8 is commendable, but the effort to support native observables is significant. Facilitating companies to prepare for this change would be advantageous. It would be more beneficial for the learning curve to be native, thanks to RxJS. Version 7 of RxJS is excellent, so there's no pressing need to introduce a major change only to transition again shortly.

Thank you for all your hard work over the years.

[adrianmcli]

I want to echo @Jordan-Hall's comment above. The comparison with Lodash makes a lot of sense. Really well written.

Having used RxJS and Observables for almost a decade, I'm really happy to see this paradigm being baked in to the Web Platform. The faster we can facilitate this transition, the better it will be for the wider ecosystem to adopt these primatives.

I am reminded of the transition from CoffeeScript to ES2015 and now the modern Javascript we have today. I foresee a similar future where these ideas will become mainstream, but it will require tooling and a lot of evangelizing. The polyfill approach can be a good start in this direction.

[benlesh]

I'd like to add that I'm pretty sure that we could also create a new @rxjs/compat package that patched RxJS-specific things onto a Web-Platform-shaped observable. Something like:

import '@rxjs/observable/polyfill';

const subscription = Observable.from([1, 2, 3])
  .map(x => x + x)
  .subscribe(console.log);
  
subscription.unsubscribe(); // ReferenceError: subscription is undefined

Observable.from([1, 2, 3])
  .pipe(zipWith([4, 5, 6])); // Error: `pipe` is not a function

import '@rxjs/observable/polyfill';
import '@rxjs/compat'; //<-- add this.

const subscription = Observable.from([1, 2, 3])
  .map(x => x + x)
  .subscribe(console.log);
  
subscription.unsubscribe(); // Happy again (but maybe reading as deprecated?)


Observable.from([1, 2, 3])
  .pipe(zipWith([4, 5, 6])); // Happy again (maybe reading `pipe` as deprecated?)

One issue is there is so much use of Observable#pipe that I'm hesitant to remove it quickly... but if we had a clean path to allow people to use it and migrate off of it at their leisure, it could work.

[Jordan-Hall]

Compact would work; however, I can't help think that migrating to abort wouldn't be that hard for people or even automated? But maybe for now adding a compat would be better for anything inside frameworks so they can still work. But I agree with the part that it should remain deprecated in IDE so people know to change

[Jordan-Hall]

Regarding your comment on pipes, if you taken the approach of Lodash but for events. When considering patching a pipe, it might be useful to compile a detailed list of functionalities that would be lost in pipes that aren't natively supported. For instance, features like CombineLatest isn't going to be native. However, this could revert to the earlier RxJS approach, where it was managed as a top-level observable rather than through pipes. As long as the solution is tree-shakable, it should be effective.

Also i would be tempted to say drop the pipe (again like pre pipes in v5) and have Observable.from([1, 2, 3]).zipWith and do this via extending the observable, plus in future if a its required and a native solution comes around its easier to migrate.

[JonathonRP]

Compact would work; however, I can't help think that migrating to abort wouldn't be that hard for people or even automated? But maybe for now adding a compat would be better for anything inside frameworks so they can still work. But I agree with the part that it should remain deprecated in IDE so people know to change

I'm actually already interopting abort signal with fromEventPattern. So this would be really nice I am doing this because I am using rxjs observables with sse (server sent events) and trpc

[JonathonRP]

Yeah that was my first thought was act as a polyfill in the interim and can have compat extension on top like lodash for pipe and ect.

[samal-rasmussen]

RxJS 8 is bringing a LOT of value already. It's about 30% smaller than RxJS 7 ... It's faster and lighter...

This sounds awesome :) This would be useful to me.

But you're saying the releasing this would be wasted work because an updated version that is compatible with native observables will be coming soon after?