Three Shifts, Not Forty Features In short: The release notes list over a hundred changes. But there are really only three big decisions. Everything else follows from them. Trying to remember a hundred changes is hopeless. It is also the wrong way to look at it, because most of those changes are not separate decisions. They are results of a bigger one. There are three decisions. Learn these, and the rest falls into place. Shift 1 — Structure: components replaced modules For seven years, the thing you built Angular apps out of was the . A component could not be used until a module listed it. A service could not be injected until a module provided it. Code could only be loaded on demand at a module boundary. Modern Angular removed that whole layer. A component now says what it needs, by itself: What came from this one decision: standalone components, directives and pipes; the list on ; instead of ; the functions instead of ; loading a plain component on demand instead of a module; route guards, interceptors and resolvers as plain functions; and later and in v22. That is roughly a third of the release notes. All from one decision. Shift 2 — Data: signals replaced streams for holding values Angular's first answer to "how does a change reach the screen?" was RxJS plus the pipe. RxJS is very good at handling things that happen over time — a WebSocket, a search box that waits for you to stop typing, a request that needs retrying. It was always a heavy tool for holding the current value of something , which is what most screen data actually is. Signals are the tool for that second job: only recalculates when or really change. And — this is the important part — Angular knows exactly which parts of which templates read it. What came from this decision: / / ; , , , ; ; / ; , , ; and Signal Forms. Another third of the release notes. Shift 3 — Updates: Angular is now told what changed This shift depends on the first two. That is why the order matters. Zone.js worked by replacing the browser's own functions — , , , and many more — with its own versions. Those versions told Angular whenever anything finished. Angular would then check the whole component tree, looking for anything that had changed. It was clever, and it meant you never had to tell Angular anything. It also meant Angular knew that something had happened, but never what . So it checked everything, every time. Once Shift 2 was done, that guessing was no longer needed. A signal knows exactly which templates read it. When it changes, it can mark just those components. There was nothing left for Zone.js to do: What came from this decision: running without Zone.js; as the v22 default, with kept for old behaviour; and Vitest as the new test runner, since tests no longer need to wait for a zone to settle. Angular's own zoneless guide lists the gains as performance, better Core Web Vitals, clearer stack traces when debugging, and better long-term compatibility — noting that Zone.js "brings a fair amount of overhead, both in payload size and startup time." Why the order could not change You could not have done Shift 3 first. Taking Zone.js away without signals in place would have meant calling by hand all over your code. That is worse than what Zone.js already gave you. And Shift 2 was much harder without Shift 1. Signals need to be created right where you declare a field. That needs to work in field declarations, which is the model that standalone startup made normal. is a field declaration. It does not fit neatly into the old modules-and-constructors world. So: structure, then data, then updates. Six years, in that order, because each one was needed for the next. Use this as a filter When you meet an Angular API you do not recognise, the useful first question is: which shift does this belong to? — Shift 1. It is about how code is put together and split up. — Shift 2. It is about data that comes from other data. — Shift 3. It is an escape hatch back to the old update behaviour. — Shift 2, right at the edge of Shift 3. It turns a server request into signals that drive the screen. This is also the right order to adopt them in. Teams that jump straight to removing Zone.js from a modules-and-RxJS codebase have a bad time. They are trying the third shift without the first two. The path that works is the same one Angular itself took: get standalone first, get signals into your data second, and only then turn Zone.js off. The architect's view The reason to hold these three in your head — rather than a feature list — is that it changes how you plan work. A feature list produces a backlog of unrelated tickets: "adopt signals", "try zoneless", "remove modules". They look independent. They are not, and a team that schedules them independently will do them in the wrong order. Seen as three shifts, the plan writes itself, because each one is a prerequisite for the next: Shift What it unlocks Why it must come first --- --- --- Structure in field declarations Signal APIs are field…