Part 3 of Angular in Production series
When an Angular application is samll, change detection is something most developers rarely think about. And honestly, that's usually fine; the framework does its job, you update some data and Angular updates the view, the application feels responsive but the problem appears later. The applicate grows and there are more components added, more state shared, more services appear and more complex screens introduced. Suddenly, interactions that used to feel instant start feeling delayed, typing in search fiel has a small lag, opening a modal feels slower and scrolling through a page with many components doesn't feel smooth.
At this point, many teams start looking directly at change detection. Sometimes they are right. But the problem is rarely that Angular's change detection exists. The problem is usually that the application has slowly accumulated unnecessary work that happens during it.
Change Detection Is Not the Problem by Itself
One of the biggest misconceptions I see around Angular performance is the idea that change detection is inherently expensive but it isn't. Change detection is one of the reasons Angular applications are productive to build. The framework needs a way to know when the UI should update. The problem starts when every update causes Angular to check a lot of things that don't actually need to change. A simple example:
