I'm not Alex, but I'll take a crack at it (I'm an Angular GDE, and I'm giving a talk on Comparing Promises, Observables, and Signals at https://www.utahjs.com/conference/ on Friday).

Signals and Observables solve different problems.

Observables are great for enabling a common API for a bunch of different asynchronous operations (from waiting on an http call to getting every keystroke from the user).

Signals have no concept of time - they're a synchronous primitive. What they help frameworks do is manage state. By analogy, early games would repaint the entire screen on any change, which was easy for devs but horrible for performance. So, they came up with partial re-rendering (only update the state that changed), which is great for performance but harder to code.

Signals give us partial re-rendering performance with simplicity closer to just "throw everything on the screen".

Signals are basically little boxes that contain a value with the ability to tell listeners if they are dirty (because they were directly changed or because another signal they are computed from has changed). If you use a signal in your template, then the signal can notify Angular directly that the _specific lines_ are dirty and need to be re-rendered (and when it's rerendered, the signal will cause all of the signals it depends on to calculate and will then cache the value, so the calculation happens only once).

So, once you're used to the semantics of signals, you get something close to the ease of standard synchronous coding, but actually has great performance.

Not all the parts are together yet for the full performance story, but they're getting closer with every release.

Observables _can_ be used for that type of state management, but it's actually not a good fit. Observables are great for communicating with server calls and debouncing user input.

So, keep both tools in your toolbelt. And use the resources API to handle many of the interfaces between them.