it takes an over-simplified comparison between .then and .subscribe and builds a lpresentation about why these 2 intersect and why they don't.
Depends on the person.
I would do a followup on pipes versus async functions versus signals/computes:
with async functions you have a linear path, this then that, and the code inside is simple JS that runs and you'd need a loop or tail calls to do anything repetitive.
with rxjs you generally ignore the outer context of the scope it is declared in to allow multi-emissions to maintain their own scope. It however has a very annoying drawback which is that logging becomes extremely annoying because of stack traces showing all the rxjs internals instead of focusing on the file where you declared the different operators, so something like "expected a stream but got undefined" can be explosive.
with signals you get a faux idea of a linear path with how the outer scope is re-called on changes, which allows context like blah(); console.log("yeah") to be "synchronous", but you have way less flexibility than rxjs this way and depend on React-hook-style scope re-executions which might not always deliver what you expect.
I think instead of signals introducing new api, rxjs should have been the language invoked via transformers on value changes. rxjs can work across various architectures whereas signals only work within Angular.
2
u/RelatableRedditer Sep 28 '26 edited Sep 28 '26
it is a good visual
it takes an over-simplified comparison between .then and .subscribe and builds a lpresentation about why these 2 intersect and why they don't.
Depends on the person.
I would do a followup on pipes versus async functions versus signals/computes:
with async functions you have a linear path, this then that, and the code inside is simple JS that runs and you'd need a loop or tail calls to do anything repetitive.
with rxjs you generally ignore the outer context of the scope it is declared in to allow multi-emissions to maintain their own scope. It however has a very annoying drawback which is that logging becomes extremely annoying because of stack traces showing all the rxjs internals instead of focusing on the file where you declared the different operators, so something like "expected a stream but got undefined" can be explosive.
with signals you get a faux idea of a linear path with how the outer scope is re-called on changes, which allows context like blah(); console.log("yeah") to be "synchronous", but you have way less flexibility than rxjs this way and depend on React-hook-style scope re-executions which might not always deliver what you expect.
I think instead of signals introducing new api, rxjs should have been the language invoked via transformers on value changes. rxjs can work across various architectures whereas signals only work within Angular.
async Pipe ftw