Proposal: move Observable back to cold-by-default semantics

[benlesh]

I want to propose moving Observable back to the original per-subscription behavior:

Every call to subscribe() starts a new execution of the Observable's subscription logic.

Sharing/multicasting would still be possible, obviously. It just wouldn't be implicit behavior of Observable itself.

I think the work in #170, #178, #198, and now #216 has actually been really useful here. The ref-counted design was trying to solve a real problem @esprehn brought up: accidentally duplicating expensive work, requests, listeners, etc.

But I think what we've learned since then is that implicit sharing creates another class of problems that are harder to see, because they're based on timing and on what other subscribers happened to do.

@jakearchibald's examples in #216 make that pretty clear.

take(3) is a simple example

Consider:

const firstThree = source.take(3);

firstThree.subscribe(a);

// Later:
firstThree.subscribe(b);

I think most people would read firstThree as something like:

"An Observable that gives me the first three values from source."

But with the shared model, if b subscribes after a already received one value, b can only get the remaining two before take(3) completes.

So now the semantics of take(3) depend on when some other subscriber happened to show up.

That's the same basic issue Jake found with fetch:

previous execution already completed:
subscribe B → new execution

previous execution still running:
subscribe B → joins existing execution

The exact same subscribe() call means something different depending on invisible timing/state elsewhere.

Cold has a footgun too, but it's at least a simple rule

The old behavior has one invariant:

Every subscription starts an execution.

That absolutely has a footgun.

If this Observable creates a fetch:

request.subscribe(a);
request.subscribe(b);

then you might accidentally make two requests when you meant to share one.

But there's an opposite footgun too: maybe the second subscriber wanted fresh data, and instead it gets attached to an old or hung request.

The big difference to me is that the cold behavior is explicit:

subscribe A → execution A
subscribe B → execution B

It doesn't change depending on whether another request happened to finish 10ms earlier.

I think the discussions have basically found the abstraction boundary

There have been a bunch of really good observations across these issues:

• @esprehn called out the real production cost of accidentally duplicating work.
• Ref Counted Observable discussion #178 explored ref-counting as a way to solve that.
• @Jamesernator pointed out in Alternative to both ref-counted and current proposal - force strategy selection at creation time #198 that sharing, replay, eagerness, and lifecycle are actually different policies.
• @jakearchibald showed that implicit sharing creates timing-dependent behavior.
• @bakkot separated setup, becoming active/inactive, and actual completion into different lifecycle concerns.
• @acutmore pointed out that the original per-subscription Observable is the more general primitive, because sharing can be built on top of it.

I think that's a pretty useful result from trying the ref-counted model.

The model that falls out of all of that is really simple:

Observable = reusable execution plan.
Subscription = stateful execution.
Sharing/replay/lifetime = explicit policy.

This is also how I think about the relationship with async generators:

new Observable(subscriber => {
  // execution plan
})

is much closer to:

async function* values() {
  // execution plan
}

than it is to the AsyncGenerator returned by calling values().

Calling the async generator creates the stateful thing that eventually ends.

Calling subscribe() does the same thing on the push side: it starts an execution. That execution can end without the reusable plan itself becoming permanently dead.

Sharing should still be easy

I don't think we need to design share() in this issue.

But I do think #178/#198/#216 have shown us that sharing comes with real policy decisions:

• replay previous values?
• close when subscriber count reaches zero?
• close/reset after error?
• close/reset after completion?
• delay closing?

RxJS ended up with a pretty configurable share() API because these turned out to be genuinely different concerns.

I definitely don't think we should copy that API directly. It's pretty library-ish and not particularly friendly.

If we eventually add sharing to the platform, I'd rather it read more like:

source.share({
  previousValues: 1,
  closeOnZeroSubscribers: false,
  closeOnError: false,
  closeOnComplete: false,
});

Something you can mostly understand by looking at it.

But that's a separate issue.

The important thing here is that those are sharing semantics, not Observable semantics.

Proposal

So my proposal is pretty small:

Calling subscribe() starts a new execution of the Observable. Completion/error ends that execution, not the Observable itself.

I don't think this means the work in #170/#178 was a mistake.

Actually, I think it was useful because we now have concrete examples of what happens when sharing is pushed down into the primitive. #198 and #216 surfaced things that were much harder to see before we had that model to reason about.

To me that feels like incubation doing its job.

We know more now than we did when the ref-counted behavior was added. I think what we've learned points back toward keeping Observable small and predictable, and making shared execution something we ask for explicitly.

[jakearchibald]

I feel we can do better than shipping something we know to be a footgun.

Consider:

const firstThree = source.take(3);

firstThree.subscribe(a);

// Later:
firstThree.subscribe(b);

I think most people would read firstThree as something like:

"An Observable that gives me the first three values from source."

It's not really that though. If the source is an EventTarget (which will often be the case), then firstThree is "an Observable that gives me the next three values from the EventTarget associated with source from the point that I call subscribe or one of the other methods that triggers execution."

…and I think that's really confusing. I can imagine developers thinking that execution happens at the time the observable is created, or when take is called. Like, take sounds much more like an 'execution' on the source than subscribe. subscribe sounds passive.

In #216 (comment) I tried to sketch out a way to make the point of execution less of a mystery.

[jakearchibald]

Compare to:

const nums = [1, 2, 3, 4, 5];
const vals = nums.values();

const firstThree = vals.take(3);

console.log([...firstThree]); // [1, 2, 3]
// Later:
console.log([...firstThree]); // []

[benlesh]

I don’t buy that we’re “shipping something we know to be a footgun.” The contract is explicit, well-established, and spelled out in the README: every call to subscribe() creates a new subscription, and nothing executes before subscription. Beyond being spelled out in the README, it's also something that's used at massive scale in the ecosystem for more than a decade.

If someone assumes take() starts consuming immediately, where do those values go before there’s an observer—buffered, replayed, dropped? That introduces far more hidden policy.

Honestly, the firstThree iterator example you posted is almost an indictment of the Iterator helpers design, more than anything else. They clearly should have been on the Iterables, which should have been a type.

The iterator comparison is also the wrong layer. nums.values() is already a stateful, one-shot execution—the analogue of a subscription, not an Observable. The reusable analogue is the generator function that creates it.

And execute() plus a new Observation type doesn’t solve this. If execute() starts work, synchronous sources can emit or complete before subscribe(). If subscribe() starts work, we’ve changed nothing except adding another object. If the first subscriber starts shared work, we’re back to the same timing-dependent sharing problem.

So we’d be inventing a brand-new exhaustible async abstraction at the last minute, diverging from the well-known Observable contract and from what this proposal has promised from the beginning. Explicit sharing belongs in an explicit sharing API.

[jakearchibald]

I can't resolve

The old behavior has one invariant:

Every subscription starts an execution.

That absolutely has a footgun.

vs

I don’t buy that we’re “shipping something we know to be a footgun.”

Are you saying the footgun issues that @esprehn experienced aren't real?

If someone assumes take() starts consuming immediately, where do those values go before there’s an observer—buffered,

Yeah, buffered. The process of taking starts when you call take. Not when you start listening for taken items. But I see your point - that doesn't play well with multiple subscribers, as the second subscriber will miss buffered items (this is also a flaw with the current hot model).

The iterator comparison is also the wrong layer. nums.values() is already a stateful, one-shot execution—the analogue of a subscription, not an Observable.

Right. My point was that take is on the equivalent of the 'subscription', not the 'Observable'. I see you personally disagree with that, but that behaviour is already part of JavaScript.

[jakearchibald]

The contract is explicit, well-established, and spelled out in the README: every call to subscribe() creates a new subscription

A bunch of methods implicitly create subscriptions, so I don't think it's even that simple.

[benlesh]

No, I’m not saying @esprehn’s experience wasn’t real. My wording there was imprecise.

Cold Observables have one basic footgun: if you consume one twice, it executes twice. But that follows directly from a simple, explicit contract: every consumption—whether through subscribe() or a terminal operator—starts a fresh execution. That can bite someone who overlooks the rule, but it’s local, deterministic, teachable, testable, and easy for tooling to reason about.

The alternatives being proposed introduce a very different class of footgun. Does this subscription join an existing execution or start another? Did that execution complete a millisecond ago? What was buffered before anyone subscribed? What does a late subscriber receive? Those answers depend on hidden state and timing elsewhere, not on the code at the call site.

That seems like a materially worse trade: replacing one predictable failure mode with several nonlocal, timing-dependent ones, plus brand-new lifecycle types with no established community knowledge or precedent. Observables have been widely used for well over a decade. If this alternative model solved a common need, I’d expect to see successful implementations of it already.

And “Iterator Helpers already work this way” doesn’t make that behavior desirable for Observable. The firstThree example returning nothing the second time is itself a footgun. We cite Iterator Helpers as precedent for the operators, not as proof that a reusable Observable should inherit the lifecycle of a one-shot iterator.

[jakearchibald]

The firstThree example returning nothing the second time is itself a footgun.

I think the difference is, if that behaviour is indeed unexpected, it's something you experience and learn pretty quickly during dev. I wouldn't really class that as a footgun.

My understanding of the issues @esprehn raised, is they were making their way to prod without anyone noticing. That's absolutely a footgun.

So yeah… I still feel that we shouldn't be shipping something we know to be a footgun.

[benlesh]

I think we’re conflating sharing an underlying producer with sharing an Observable execution.

It’s completely fine for EventTarget.when() to use one native event listener internally and fan events out to every subscription. That’s an implementation detail. Each subscription should still have independent operator state, cancellation, and completion. Two subscribers to when("click").take(3) can share the same DOM listener while each getting their own three clicks.

Cold Observables have one basic footgun: consuming one twice may duplicate work. But that follows from one explicit, deterministic rule: every consumption starts an execution.

Trying to eliminate that one footgun introduces several worse ones:

• A subscription may join existing work or start new work depending on invisible timing.
• A late subscriber may miss, buffer, or replay values depending on additional policy.
• take(), completion, errors, and cancellation may become shared or exhaustible state.
• Ref-count teardown and restart behavior races with subscribers arriving or leaving.
• If execute() starts synchronous work before subscribe(), values must be lost or buffered.
• Reusable derived graphs become one-shot, forcing developers to introduce factories everywhere.

And that last point recreates the original “footgun” anyway:

const createObservation = (): Observation<T> =>
  observable.execute();

Does calling createObservation() start new work every time, or does it return a cached/shared execution? The type cannot tell you. () => Observation<T> reveals no more about its captured producer than () => Promise<T>, a callback-taking function, or an Observable does.

If it creates a new execution every call, we’ve recreated the exact duplicate-work footgun we were supposedly eliminating. If it returns shared work, we still have all the timing, lifetime, and late-subscriber ambiguity. We’ve just moved the problem behind another abstraction.

Observable is a primitive, like a function. One call means one function execution. One subscription means one Observable execution. What that execution does internally—including whether it uses a shared listener, cached request, or other shared producer—is an implementation detail.

That is one simple contract. Replacing it with more types and hidden temporal state seems like a much worse trade.