Angular’s latest releases bring a wealth of actionable advice on building scalable systems, trimming down animations, and fine-tuning performance.
This week, we explore how domain-driven design translates to frontend work, what steps in for the deprecated @angular/animations package, and techniques for minimizing reflows using Angular’s render hooks.
Domain-Driven Design in the Frontend
Domain Driven Design (DDD) enables us to break a large system down into smaller, cohesive pieces. The outcome is often modules that are strongly decoupled from one another—precisely the kind of isolation we look for in a scalable setup.
Manfred Steyer at Angular Architects has spent a good amount of time talking about DDD within Angular, and lately he dropped a fairly comprehensive write-up on the subject.
He kicks off with the reasoning behind DDD and then walks through the vocabulary we rely on, such as Bounded Context, Ubiquitous Language, and Context Mapping.
Since DDD is frequently encountered on the server side, it's typical that we can reuse the same separation points over again. Plus, there's the recurring question: if the backend already enforces boundaries, does the frontend actually need explicit ones?
For an answer, Manfred explores Event Storming—a method that both surfaces domains and bounded contexts from the start and shows whether independent frontend models are warranted. Therefore, treating the frontend as its own bounded context becomes necessary, especially for highly complex applications.
Manfred keeps things practical, not just theoretical. He covers how to translate domains and boundaries into code—whether via separate apps, libraries, or plain directories—and weighs the advantages and drawbacks.
Readers who are already familiar with DDD still stand to benefit from this thorough piece.
DDD in Angular & Frontend Architecture: What you need to know - ANGULARarchitects
Learn how to structure complex Angular apps using Domain-Driven Design (DDD): Bounded Contexts, vertical slices, Nx, Sheriff, & Micro Frontends in practice.
angulararchitects.io
Future of @angular/animations
For a long time, @angular/animations has been a staple of the framework. But over time, various problems have come to light. A key one: many animations no longer require a library, since browsers handle them natively.
Consequently, sticking with @angular/animations comes at a cost—it runs on JavaScript, forfeiting hardware acceleration and dragging down performance. The library also bloats our bundles with extra scripts, and integrating well-known third-party animation packages can be a pain.
Despite this, the Angular team aims to offer a straightforward, ergonomic solution for animating elements as they enter or exit the DOM.
In short: plans are to deprecate @angular/animations, replacing it with lightweight animate.in and animate.out bindings. Mirroring the new control flow syntax, these will be built directly into the framework, requiring zero extra imports.
An RFC is currently open for public input, along with a StackBlitz demo to try out the feature.
https://github.com/angular/angular/discussions/62212
Optimizing Reflows
Wrapping up, Alex Rickabaugh delivered a 15-minute talk on the reflow challenge tied to afterNextRender. Reflow refers to the browser's recalculation of element layout—think dimensions or positioning—triggered by DOM or style modifications.
Typically, the browser schedules reflows efficiently. But performance can suffer when JavaScript synchronously reads layout-dependent properties, such as offsetHeight or getBoundingClientRect(). Such reads demand an immediate reflow, which might fire prematurely in the frame's lifecycle.
Another pitfall involves reading a layout property and then performing a separate write operation. In that scenario, it's wiser to rely on the browser's scheduled reflow, preventing redundant layout calculations.
To aid these optimizations, afterNextRender and afterRenderEffect let us declare whether our code will read or write to the DOM, enabling Angular to sequence operations optimally.