71–80 of 84 posts
Earlier quoted context omitted.
React reacts to changes in state or properties by automatically updating the UI. What's not reactive about that?
Its entire state management is not reactive, it’s always on push, not pull. You always need to call setState to get render changes.
I've gone back to advocating Angular because it has been making a major comeback. It's genuinely awesome now.
Earlier quoted context omitted.
Are projects still chosing to pick RxJS (or equivalent) which make the code heavily layered and a pain to debug? Or has sanity reached the Angular ecosystem by now?
The problem with Angular is that the http client service used to return observables by default and that made people think that you had to use them as such. It was a mostly useless, massive pain. Working with Angular became a pleasure the moment we decided to just cast our service calls to promises. For the rest, RxJS is cool where you actually need it and want it.
Regardless signals is also fine, we have ways now to interop between rxjs to signal for those looking for it:
https://angular.dev/api/core/rxjs-interop/toSignal
Personally the http client workflow is fine. Usually lives in a service and exposes the needed values in any form we want.
Using angular in 2026 is mad :D
Earlier quoted context omitted.
Are projects still chosing to pick RxJS (or equivalent) which make the code heavily layered and a pain to debug? Or has sanity reached the Angular ecosystem by now?
The problem with Angular is that the http client service used to return observables by default and that made people think that you had to use them as such. It was a mostly useless, massive pain. Working with Angular became a pleasure the moment we decided to just cast our service calls to promises. For the rest, RxJS is cool where you actually need it and want it.
I still use RxJS, but mostly in the top-level component and/or service who orchestrate between data, url state and api responses. Those top-level page usually keep the default change detection instead of the 'on-push' strategy).
A few years ago I was in the process of abandoning Angular in favor of React. I've gone back to advocating Angular because it has been making a major comeback. It's genuinely awesome now.
React shines when it comes to the composability of components, eg. for data-table with customizable rows. It's still possible in Angular, but it's heavier.
For the rest (syntax, the ecosystem, routing, data-handling, DI), Angular is so much more straightforward. Services with dependency-injection is 99% of the time way simpler to reason about than React hooks, especially when you start to need cascading changes between hooks after user interaction.
Out of curiosity I’ve progressed away from Angular around 2018. My peak spa-ish reduxian state management experience was building an NgRX combo with @ngrx/effects for side effects. Till this day I remember this fondly as it gave me so much ease of control of the application’s many complex states. Especially when I nowadays deal with all sorts of false-prophets in forms of hooks and what ever reactive primitive du-jou…
Earlier quoted context omitted.
UI is reactive, not state. You push changes to state and UI reacts to it.
A derived state is certainly reactive.
"The react in react stands for reactivity, however it is not." [because] "Its entire state management is not reactive"
React is primarily an UI library, not full state management library. And its UI is reactive.