Where Reactive Forms Strain In short: Reactive Forms got a lot right and held up for a decade. It also has four problems that patching could never remove — because they all come from one design decision. Explicit form structure in the class instead of scattered across a template. Values and validity you can read straight away. Validators you can combine. Streams for reacting to changes. It is a better design than most frameworks shipped. The central decision In Reactive Forms, the is the truth. Your data is something you pull out of it. This is a sensible design. It is also where all four problems come from. Problem 1 — you describe the same shape twice You have an interface describing your data, and a describing the same shape in different words: Nothing connects them. Add a field to and the form quietly does not have it. TypeScript cannot help, because the is not described in terms of — it describes itself. Loading and saving means translating between the two shapes by hand, both ways, forever. Problem 2 — typed forms could not finish the job v14's typed forms were a real improvement, and they ran into the "might be empty" problem. A starting at has the type "string or empty", because empties a control. That is honest about what happens, and it means every read needs handling: fixes it one control at a time, and changes what does. Meanwhile is a partial object — because disabled controls are left out — so even a fully non-empty form gives you an incomplete object at the exact moment you want a complete one: The usual workaround is , which includes disabled controls. That the unusual name serves the usual need is a good summary of the friction. Problem 3 — validation must be triggered by hand Validators are functions given to a control when it is created. When a validator depends on something outside its own control, you have to tell the form when that thing changes: exists because the form has no way to know a validator's inputs changed. Forget it and validation is quietly out of date — the field looks valid against a rule that no longer applies. It is a common bug and it produces no error. Checking two fields against each other has the same shape, plus an awkward placement problem — the validator goes on the parent group , so the error lands on the group rather than the field that is actually wrong: Showing that error next to the confirm field means reaching up to the parent in the template. Every project has a slightly different helper for this. Problem 4 — dynamic forms are long-winded works, but everything about it is manual: The list is handled through its own API rather than as plain data. And , , and are text , so renaming something in the class is not caught in the template. What was genuinely good Worth saying clearly, because "Reactive Forms was bad" is wrong and leads to unnecessary rewrites: Structure in the class , so it can be tested without drawing anything Values and validity readable straight away Validators you can combine — genuinely useful for auto-saving — made any component work as a form field Well tested. A decade of edge cases found and fixed. Signal Forms keeps all six ideas. It changes which shape is the truth — and that one change removes all four problems. The pattern behind all four Each problem is the same thing: two shapes that must agree, kept in agreement by hand. Your data and the — kept in agreement by you What happens at run time and what the type says — kept in agreement by flags A validator's inputs and when it runs — kept in agreement by The and the underlying data — kept in agreement by and Remove the duplication and all four go with it. "But didn't typed forms fix this in v14?" Typed forms were a real improvement and they fixed the smaller problem. They made a control carry a type. They could not make the and your data be the same thing — and that is where the friction lives. Two things survived typing: "Might be empty" from . Honest about run time, still a nuisance on every read. Partial objects from . Even a fully typed form gives you an incomplete object at the moment you most want a complete one. And the duplication was untouched. Add to your interface, and the typed still does not have it. The related myth: "template-driven forms are the beginner option." They were never wrong, just limited — structure lived in the template, so it could not be tested without drawing. Signal Forms takes template-driven's lightness and reactive's testable class-owned structure. It is not a third compromise. It is the combination that was not previously possible. Cheat sheet Which problem is biting you? Symptom Problem --- --- Added a field, form quietly lacks it Duplication or on every read Might-be-empty everywhere Partial objects Validation quietly out of date Missing Error shown on the wrong element Group-level validator placement code longer than the feature Dynamic forms What Signal Forms keeps — so migrating is not a re-learn: Reactive Forms idea Signal Forms --- --- Stru…