vue was started with signal like,

Signals will be much simpler conceptually than RxJS, so prob makes sense to throw it into the mix right away when it's available (if you can)

​@@JoshuaMorony Thanks for your advice! I'll give it a try 💪

i like your thoughts

I think the mental model for signals is a lot more intuitive while mostly keeping you from making common mistakes that can really easily happen in rxjs. As mentioned in the video it will be powerful enuoght for most usecases. And it is easy to fall back to rxjs for the rest.

i think you are mostly right, but i would argue that there are some things that will be much more straightforward. and of course there are also the performance benefits and the potential to (altough probably not very soon) ditch zone.js altogether

Well said.

signals make me feel like a beginner already, they look like react hooks, why the new stuff when we can just build on what we have, dozens of beautiful rxjs operators put to no use. Tbh even though I dont know them all I rather would like to one day then learn new library, learn new library. But tbh rxjs docs is not down to earth at all thats why no one can learn them. We need some down to earth rxjs docs tbh

Check out DecodedFrontend if you haven't already, probably already has a video on this and will do a better job/has better knowledge in that area than I do

@@JoshuaMorony Thanks, will do!

I'm currently creating a schematic for a library at work as well. Schematics are brilliant for reducing boiler plate, but I found the documentation of it quite lacking. I suggest you try to read some schematics from other open source projects to get a feel for what's available with the Angular libraries when creating schematics. I recommend the DecodedFrontend video as well, as that was a good starting point 👍

This is what I like about RxJS too, but you can still get this same effect with signals by using computed - the only part you can't do with signals in this way is the situations where some kind of async process is involved (e.g. http), so it still makes sense to keep RxJS around - either converting to/from signals where required, or maybe starting your data in observables in your services etc. and then convert those to a signal at the component level.

I haven't got into this specific circumstance yet, but no you shouldn't need to use CDR, but also the current implementation of signals is a super early prototype and still relies on zone.js under the hood. At the moment I think the preview is more about just exposing the API to us - so it could be that there is some problem in the code you're using, or maybe it's just something unhandled/unimplemented in the signal API

When signals are generally available, I think swapping BehaviorSubjects with signals will probably make sense for most people most of the time - but in some cases you might need more RxJS stuff, so might make sense to stay in "observable land" and convert to a signal closer to the template. I think signals by default is going to be a good idea though.

@@JoshuaMorony yeah my thought exactly, Signals seem to target the direct view update, not the overall app state.

This is sort of cheating I guess because it uses my signalSlice utility but here's something I've been playing with (I have a video on it coming out in a week or two): github.com/joshuamorony/signal-slice-forms/blob/main/src/app/home/home.component.ts

I will probably slowly migrate all of my content on all of my platforms to use signals by default (with RxJS in places where needed still) - might take a little while though!

It doesn't need to be mutable - you can just not use "mutable" and the flow is more or less the same as RxJS (e.g. composing signals with computed, rather than composing observables with pipes). Still reactive/declarative in the same way RxJS is, just less power than RxJS has available.

@@JoshuaMorony I am not sure if it is really fair to say it signals have less power than rxjs. I think in terms of perf optimization and glitch prevention signals are much more powerful than rxjs. They just are not as powerful in some cases that rxjs shines. But as you said in the video it is it is not a replacement for rxjs. They are meant to really work together and make complement each other.

These implementation details have not been settled yet - maybe eventually signals become the default CD strategy, in the short term maybe we have a "Signal" CD strategy that we can define per component or something like that, but that remains to be seen!

@JHades Dev @Joshua Morony I’m both confused with this question and answer. Assuming we’re using OnPush strategy, I understood CD as something that it can be triggered. In many cases were they triggered by observables (for example when you use an async pipe in your template) but they didn’t have to be. You can also mutate a Component’s field with a @Input decorator or inject the ChangeDetectorRef in your constructor and then later trigger CD by calling detectChanges on a synchronous operation. My point is, the change detection lifecycle has nothing to do with weather you’re using observables, async/await or signals. But I’m here to learn and I’d like to know why that is not the case (if that is true)

​@@tinnick if we ignore backwards compatibility stuff/usual deprecation schedules etc (which won't be ignored of course, this isn't going to be a breaking change) - but for explanation sake - what signals would allow Angular to do is get rid of OnPush entirely, as you've mentioned it is this kind of special approach to CD where you follow certain rules and it will mark sub trees of your application as not requiring the normal global dirty checking that Angular does. If we make signals the default change detection strategy in Angular then we don't need zone.js, we don't need to worry about checking things like input bindings/references, we don't need a mechanism like the async pipe that will make a component to be checked. Angular will know what parts of your application need to be updated just by virtue of the fact that a signals value has changed, and it will be able to more precicesly target/update just the specific part of the app that updated, without having to dirty check the entire component tree - just that one component or perhaps even just part of that one component.

@@JoshuaMorony So in the example you shown in this video, neither zones default change detection OR OnPush was active, neither was active, it was all just signals, correct? and how do you turn that on on Angular 16 RC branch, is there a special API property that you need to set in a component? Thanks for sharing, love the videos, cheers

@@jhadesdev9576 no this has not been implemented yet, the Signals API right now just uses the default change detection mechanism/Zone.js - I think the general API is the first focus, then CD stuff. This is a very early prototype (though I suspect it will only be in the order of months until we see a full/stable release of signals)

Yeah I think we have more or less the same sentiment: people who like/use RxJS now will continue to do so (and integrate signals to varying degrees), people who use RxJS now but only because they have to will probably migrate entirely to signals, and I also agree that very few new Angular developers will adopt RxJS. So overall, a significant decrease in RxJS usage overall I think.

Thanks! I think there are still a lot of other differences between React and Angular, but in any case I don't think it's really a "drive to simplicity at a cost of control over events" - RxJS will still be there to use when required, I see it more as decoupling the need to use RxJS for simple situations that don't necessarily need it. Using RxJS for simple situations isn't that big of a deal if you already understand it, but for a core "reactive primitive" in the framework I think it's a lot of mental overhead to bring in say for just filtering an item from a list. One of the most common Angular criticisms is always the steep learning curve, and I think this can help soften that whilst still having those advanced features available to people who need them.

Angular is the matured professional framework, it has simple syntax than react. React is hard to understand, the DX of react is horrible. React is a child play. When it comes to serious enterprise app development, Angular comes in glory. React has brought shame to JavaScript community by making web development unnecessarily complicated.

Ugh God no. Give people an easier way to write better applications, instead of the imperative mess the default change detection facilitates.

I agree that using RxJS in conjunction with signals is a better idea - but if RxJS is more of an "add on" that you get to choose to add in or not, it's a big ask for most people to invest in learning it. RxJS is probably harder to learn than Angular itself. So I think most people won't learn RxJS, and I think the proof for that is in the fact that it is barely used in other front end frameworks (despite it being a valuable tool to deal with the sort of async reactivity problems that also come up there)

I feel that this will lead to MORE readable, but also more bug ridden code. Rxjs code is many things, but easily readable isn't one of them. I feel that most developers will gravitate towards cleaner looking, and easier to understand, imperative coding styles, which will include many of the downsides that currently exist with imperative code, just like they do now.

@@jaredwilliams8621 Why do you think that it will be more bug ridden? I think signals (as mentioned in the video) are much less likely to lead to errors than rxjs. The synchronous nature and the glitch free execution of the reactivity of signals gives you much more guarantees than you get with rxjs. Therefor its much less likely to get error ridden code in most scenarios. Maybe you mean that you could miss the point where you should switch to rxjs. But I do not think that this is more error prone than doing everything in rxjs without the experience needed to do it right. And if you have the propper experience in rxjs you will be able to work with signals without getting into errors.

Maybe I'm just not thinking innovative enough, but I think for signals to deal with what RxJS deals with it would just end up basically being RxJS with different syntax. Maybe a targeted set of things to handle the most common use cases could be integrated at some point? I would be surprised to see it - I think it just makes more sense to have the RxJS interop stuff

If we get control over scheduling of effects (pull phase) then most of the common async usecases could be managed. Only leaving the really complex ones to be handeled best by rxjs. Glitch prevention is one of the strenghts of signals that can get really hard in rxjs. This is something also async usecases can really benefit from.

Well yeah for those who work with streams in other languages it is very easy to understand, but i noticed that a lot of FE developers have no understanding about general concepts and don't see the bigger picture.

Sure, but most java devs act like you literally physically assaulted them when introducing this stuff! There's a huge 'sigh of relief' as 'virtual threads' are promising to eliminate the need for java devs to modernize their monolith mindset.

@@adambickford8720 Partially correct. There are lot of enterprise java devs how are absolutley familiar with modern concepts. It's a big community who is very aware of what is happening around them, especially in the spring/spring boot world. So i think i have to take a stand for the java community, those people are pretty aware and open for such technologies.

@@returncode0000 I work almost exclusively in java spring and its specifically WebFlux I'm talking about! The vast majority of the devs HATE the entire reactive stack. No JPA, of all things, was the first dealbreaker. They are thrilled to avoid learning concurrent programming and are salivating at (ab)using the parallel programming they know and love. You're right though, it's a huge community. My PoV is from the fintech space that won't consider something like rust for another 10 years.

@@adambickford8720 Many decisions about technologies are mostly driven by the company's strategy or the environment given by the market. I think thats especially the case in fintech but also at my work which is a very big enterprise. We have some freedom to do things as we want in our teams. But I agree with you some folks don't want to change things.

If you want a donation that also gives you the benefit of a lot more reactive/declarative content Ionic Start is a good idea (even if you're not using Ionic, it's ~80% Angular) - otherwise, no worries! Just glad to hear you're enjoying the content!

I think it's fair to say imperative code is easier to reason about, but I think that declarative code is easier/quicker overall to follow/understand (but that requires learning the concepts first of course, which is by no means easy)

For trivial examples? Sure, but that's true of 'goto' as well. EVERYTHING is easy in a small enough scope.

Good to be aware that's what you're doing (which I suppose the method naming makes more obvious) but mutation can be ok and is sometimes preferred

@@JoshuaMorony My intuition tells me it's problematic but maybe that's because I think of react's useState

I agree that in an ideal world Angular devs would all like, use, and understand how to utilise RxJS. I just don't think that's happening though, and I think we are going to trend toward lower RxJS adoption. I do think there will be a sizeable community of RxJS devs within Angular that remains though, and I can see it remaining as something that people continue to learn as they advance their Angular skills more.

RxJS is great and I love working with it, but let's face it, the default approach to Angular for most people is to imperatively code everything and use RxJS as little as possible. I think signals is meant to change the default approach by introducing something that's a bit easier to understand upfront. RxJS will never do that, and it really sucks to work with non-reactive Angular.

I get that feeling, but I think the problem is that front end development is (or can be) that complicated. We have all these complicated things we need to deal with, so people create tools and frameworks and strategies in an attempt to make those things easier/more consistent/more performant/maintainable etc. But it's always tradeoffs and "it depends", sometimes you have a lot to gain from these frameworks and libraries and sometimes you don't, and it can be hard to tell when it might be worth it and what the right approach might be if it is.

What biased opinion do you think I'm making here? To be clear, I'm not trying to say signals is a general replacement for RxJS - I like RxJS, and will continue to use it, but RxJS already has relatively low adoption in Angular even when it is included by default and required to use many parts of Angular. I can only imagine that adoption will decrease when RxJS is no longer a "required" part of Angular. I don't think people not using RxJS is a good thing, I just think it is what will happen.

@@JoshuaMorony You gave a clear percentage on how things will replace each other, but now you are denying it. Watch the clip please. My debate is simple. RxJS and Signal are different techs for different use cases. They are not replacements. You are entitled to your opinion regarding RxJS adoption in angular. I believe many have completely opposite opinion. Me included. Respectfully.

​@@sohail2d I mean not a "general replacement" in the sense that signals can not do everything RxJS can do, but they can do a lot of what RxJS is typically used for in Angular applications. The 90/10 wasn't intended to be some kind of precise number, it's going to vary from codebase to codebase - but (assuming someone is seeing if they can replace RxJS with signals) I think somewhere in the realm of 10% would be a decent estimate of the average amount of situations in Angular codebases that would require RxJS (as in you couldn't replace it with signals without losing something/introducing a bug/race condition). Signals and Observables are different and cover different use cases, but there is also a lot of overlap. I want more people to learn and use RxJS, I love it. I think people *should* use it, I just don't think they are going to. Given that RxJS has been more tightly integrated with Angular and we had something like 50% adoption (this one isn't just a made up percentage, though I don't have a link to the survey the Angular team did) - essentially 50% of Angular devs liked RxJS and wanted more of it, 50% of Angular devs did not want to use RxJS. Now that there is this push from the Angular team toward signals as the default reactive primitive, I just can't imagine that increasing the number of devs who pursue/learn RxJS. Edit: To be clear, I think we will still have new people who adopt/learn RxJS, I just think it is going to be a relatively low percentage of Angular devs

@@JoshuaMorony Well lets agree to disagree. I've been coding long enough (3+ decades) to witness rise and fall of several libs/solutions/methodology/etc. Here is my 2 cents: 1. If a concept has been already adopted (even 50% as you mentioned) introducing a different way to achieve the same result simply won't cut it. (i.e. new coding style) 2. Improving the pain points of prev concept has better chance of adoption, also 3. When it is about adoption, overlaps simply weaken each other (i.e. scriptaculus.js prototype.js, ...) Personally, I find solutions that "do one thing and do it right" have a better chance of survival compared to "overlap"ed approach. Because: - as a developer it means less technical debt, and - as a c-suit it means better maintainability and scalability. Truth to be told, Signal is not a new concept. In fact with a bit of digging you can find the trace of what is trying to solve back in 2005-2007. When a couple of major js frameworks were introduced in 2010, signal (back then state management techniques) gained a bit more traction. My point is, different names in different times with the promise of solving the same problem (or overlapping to other territories) is not a reliable or permanent solution. Chances are it might be a buzzword... evolving into another buzzword in another time. Time will tell.🤷

@@sohail2d For sure, I'm not even 100% sold on my opinion anyway (and you make good points) - just what I think is more probable given that Angular has decided to go down the signal path rather than focusing on RxJS specifically, but I'd certainly be glad to be wrong and have an increased level of RxJS adoption among Angular devs

Rxjs is for control flow. Not performance