Why didn't the Angular team just use RxJS instead of Signals?

Signals seem to be pretty much what knockoutjs did many years ago. Feels kinda weird cause that's what I used before angular, til 2018, 2019 xO Still I can see its benefits.

This feels like knockout…

Actually combineLatest example may be incorrect: derivedValue going to emit 20 after valueOne.next(2), but it’s going to happen before valueTwo.next(20), so there not going to be “transitional value” in this case

on what basis did computed() wait for both values to be updated before computing. the changeValues() funciton to complete?

I love mobx and signals are just mobx rebranded

Could you avoid the double broadcast of combineLatest with a debounce operator (maybe if you anticipate sources updating "at the same time?"

Simple and effective super and well explained

Thank you for posting this!

We used to use ClearCase, and everytime I suggest git, people will say, ClearCase has all the same features and lot more, just check the docs and learn it properly. Kind of same with RxJs. Simplicity is under appreciated.

Great comprehension, no shit talk just real coding and explanation, I liked it much.

Great video I would like to see a video on how Signals is able to achieve glitch free computation.

Very nice explanation. Thank you

Ok, I see signals are "glitchfree" but for our applications its okay to have those "glitches". The users can't see them and we love rxjs so we will stay with it. Once you got used to rxjs and it's power it immediately speeds up productivity and keeps the code very clean. Also I do not want to have a mix between signals und rxjs because it makes the code more complex 🤔

I noticed most people struggle with observables when they try to learn Angular and is often the reason people switch to other frameworks like vue or react.

Nice explanation, thanks!

As someone who is a huge fan of rxjs and tries to help jr devs at work write more reactive code, I love signals. It so simple to use and for people to understand after spending some time with it. I can't expect someone that's been working on Angular for a months to be as comfortable with rxjs as me whose been using it since Angular 2 first came out. Signals makes it so much easier to not fall back to the non reactive coding patterns that alot of jr devs usually do.

Thank god. I was just beginning to learn RxJS and it was so difficult i quit for a bit. Now I"m going to learn Signals instead

Actually - i like angular got signals a lot.. Good points - especially about rxjs and how it hinders angular adoption... it's always a pain to check all the rxjs code of beginners for all this stuff... signals will make development easier for so many...

RxJS and the concept of observables I think is the main reason new developers try to stay away from Angular. It is more of a new concept for most of us and you really need to learn it. Facing that big learning curve will surely intimidate devs who are new to Angular and will think Angular is full of shit and unnecessary complexities. I agree that it is a good thing to introduce Signals with Angular as it is way much simpler and straightforward. I use RxJS in all of my Angular projects for years now and I dont even utilize those complex operators in most of those projects(except for a few features and requirements). I find signals to be enough for my needs.

So after 7 years Angular finally gets some DX... sorry but most of the world has moved on lol.

Interesting! A big difference I'm seeing is signals are synchronous while observables are asynchronous when you want to access a value, which has big implications. I guess I'll have to try signals in my next application. I would be tempted to use it in my current one, but that's going to be a big refactoring that I can't afford to do.

Not being able to get the latest value emitted by an observable is probably my greatest annoyance with RxJS. Sure, it's not something you should ever need in a purely reactive codebase, but a lot of the time you are not coding fully reactive, and in those cases it sucks to not have this basic feature.

I wonder how I can separate the changes in the effect, when which "signal" or "computed" has changed?

Great info Joshua! Thank you for clarifying signals with real examples vs RxJS. It looks they are easier

All "problems" (I would say side-effects) you mentioned are actually very EZ fixable in RxJS, so I it's not so cut and dry. However one has to have some experience to see those side-effects immediatelly during writing the code. Only real difference I can see is in writing less code out-of-the-box, which can be erased by writing one single cutom pipe and apply it anywhere you want. Then the practical difference is going to be mySignal vs my$.pipe(signalLike())...
Still, it's great to have that extra option as it makes Angular more approachable and predictable to newcomers

Nice Explained

The average developer would have spent about 5 6 years learning the patterns of rxjs as well as its drawbacks and glitches. But now: time to throw that out the window and wait for some state management that uses signals instead of ngrx and refactor that. It's good. I make more money, I sound smart and trendy by using the latest trends, its all the dream of any developer 😂.

Fireship rip-off?

Great explanation, thank you!

I've learned a lot (everything) about RxJs watching your videos... Now that I understand 30% about it, Signals appears in the picture 😥

Am I the only one who knows that Angular is becoming similar to Vue?

While I agree that signals are easier alternative, I want to mention that your example during the side effects can be simply fixed by using shareReplay(1) method, that way your log will only trigger once

Very good and informative. I'm looking forward to getting stuck in to Angular 16

Fun times ahead with more friction with state management justifiable with signals and side effects. Hopefully, this brings the community together and avoids class files with 40 mutated values in them, right? Nobody still? Ok cool.

Thats exactly the video i needed to understand the purpose of these signals, thanks !

Practical video :) love it!

IO ♥ Rxjs

It's a pretty handy utility, but I already see the overuse of signals and even more complex components.

What I'm missing here is the fact that these two serve to a different purpose. All these "issues" can be solved with operators, and with Signals new issues will pop-up, just as with computed properties in EmberJS. I see them more like RxJS being data provider and Signals used to deliver this data. Anyway good video

this is more like a demo of all the things wrong with RxJs and frontend dev 😂😂😂

Hey, thanks for the great videos. I like your presentation of the material. May I ask what color scheme or theme you use in this video? Can you share?

Something that you did not mention(unless I missed it): an effect(() => {...}) created inside a component gets destroyed automatically when the component gets destroyed, unlike RxJS where you need to unsubscribe/takeUntil.