Angular v22
blog.angular.dev
blog.angular.dev
I wish Angular dropped their weird compiler that's tight coupled to tsc and moved into more pluggable approach so you can use it with whatever TS compiler. App and unit test cold build times are still crap, but at least with a coding agent you care about this less.
Or has sanity reached the Angular ecosystem by now?
I would be more happy if it would be just one of those..
Promised - async
Observables - streams
Signals - reactivity
> Signals - reactivity
The r in rx stands for reactive.
I suppose we can say that there are different kinds of reactivity. Signals is one kind. Observables à la rxjs is a different kind (the whole model of programming with rxjs was referred to as "functional reactive programming"). Observables are push-based. Signals, as I heard, are a more complex primitive, which, under the hood, is push-pull.
React's reactivity model may be crap; but this doesn't make it non-existent.
Since react doesn’t have a true reactive model, you need to subscribe to changes manually (use effect) to create computations, while in signals it’s a primitive (computed).
I actually created a lib that operates signals over reacts state management (https://roypeled.github.io/react-logic/), so I removed the boilerplate to create a true reactive system.
If you want, you can create reactive system just from JS primitives, using callbacks. But that doesn’t make JS reactive by nature.
How do you mean? Since the render function reruns during every update to state/props, derived/computed values can be calculated from the updated state/props during rendering.
"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.
Until this release (if you only use stable features) using forms meant dealing with observables too, even if you just want to read data when submitting a form and validating some data on change/blur.
And often you’ll find that your data from promises, observables and signals need to interact with each other, which can be annoying.
Fortunately the situation with signals and their async usage is improving, and iirc the Angular team wants to make rxjs optional, but until it is Angular can be a confusing mess on some points.
Regarding angular I agree, rxjs was a bad choice for data management, and before signals arrived I abandoned rxjs in favor of mobx in my angular projects. However you could roll your own http client, we used axios, and using DI it’s a drop in replacement.
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.
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).
With that said, the autocomplete example which parent mentioned, does seem well made. Was just surprising to see such a basic mistake in the documentation for the accessibility stuff, one would think they would take extra care to get it right there, as that's what people (and LLMs...) will read and retain.
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-jour (don’t get Me wrong they are 80% of the time the better choice, it’s just that they don’t scale).
What’s today’s version of complex state management in Angular-Land?
Signals and signal stores make it very easy.
Did the whole coding by hand, no ai coding tools too.
import {signal} from "@angular/core"
import {form} from "@angular/forms/signals"
So, signal comes out of core and form comes out of forms/signals. This must be a terminology thing I don't get.Other than that. Looking forward to try Angular again after a decade of absence. I think it looks pretty good.
React/Vue/Svelte are view libraries that give you more flexibility.
Angular gives you structure.
For large enterprise apps with many developers, consistency and standardization is often the main reason people choose it.
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.
I'm pretty sure in this late game, all the frameworks are more-or-less the same in terms of render performance. Angular has a lot of cool tricks (with these signals) that allow for only re-rending what changes.
I'm not on the Angular development team or anything, though I do use Angular at $DAY_JOB and I'm overall perfectly fine with the framework and its tooling. However, the grass might be greener elsewhere; I'm just not familiar with it!
Has anyone done a modern Angular vs. React comparison that's not an AI slop article?
I'm also curious if it's "simple made easy" for performant applications. React is arguably "simple made hard", but there are notable, highly performant applications written with it (Linear comes to mind).
Source: Just look at what's been in the last couple years of updates.
I only touch it when doing projects like Sitecore, Contentful, Sanity, and co, where React/Next.js are the official extension points.
So many hooks, use "this" and "that".
I would still rather use something else (instead or React or Angular) but 1) most jobs in my area are asking for one of those, and 2) I'm actually starting to lean towards Angular even for personal projects.
Angular is great these days, and they're making really nice improvements.
I hope more teams give it serious consideration as I just am not excited about dealing with React and it's numerous spinoffs.