Scalable architecture, lean animations, and performance tuning — this week’s Angular updates are packed with practical insights.
We look at how DDD applies to the frontend, what’s replacing @angular/animations, and how to optimize reflows with Angular’s new render hooks.
Domain-Driven Design in the Frontend
Domain Driven Design (DDD) helps us slicing a large system into several smaller parts. That could result in modules with a high degree of isolation. Exactly what we want for a scalable architecture.
Manfred Steyer, from Angular Architects, has been covering DDD in Angular for quite some time, and now he has released quite a huge article about that topic.
He first starts with the why and then discusses the terminology we use. For example: Bounded Context, Ubiquitous Language, Context Mapping, etc.
DDD is quite common in the backend space, so very often we can already reuse the same boundaries. Nevertheless, a common question is whether explicit boundaries are actually required for the frontend if the backend already has them.
To get an answer, Manfred writes about Event Storming, which is a technique that not only helps to identify domains and bounded contexts in the first place but also indicates whether separate models for the frontend are needed. So, the frontend as a bounded context is a reality which especially quite complicated applications have to face.
Manfred doesn’t stop at the theoretical level. He also goes into implementation details — how domains and boundaries are put into code via its own applications, libraries, or just folders — and discusses the pros and cons.
Even for people with existing knowledge in DDD, this extensive article is worth reading.
All about DDD for Frontend Architectures (with Angular & Co.) - ANGULARarchitects
angulararchitects.io
Future of @angular/animations
The @angular/animations library has been part of the framework for quite some time. Over the years, however, several issues have surfaced. For example, many animations can now be handled natively by the browser.
This means that if we still use @angular/animations, we lose performance, since it’s JavaScript-based and doesn’t benefit from hardware acceleration. On top of that, the library adds unnecessary JavaScript to our bundles, and popular third-party animation tools are often hard to integrate.
Still, the Angular team wants to provide a simple and ergonomic way to define animations when DOM elements enter or leave the page.
The short story: @angular/animations will be deprecated. In its place, Angular introduces lightweight animate.in and animate.out bindings. Similar to the new control flow syntax, these will be part of the framework itself—no need for additional imports.
An RFC is now open, and you’re invited to share your feedback. There’s also a StackBlitz if you want to give it a spin.
https://github.com/angular/angular/discussions/62212
Optimizing Reflows
And last but not least, Alex Rickabaugh gave a 15-minute lecture about the reflow problem in the context of afterNextRender. Reflow is the process where the browser recalculates the layout of elements — such as their size or position — after changes in the DOM or styles.
Reflow is usually efficiently scheduled by the browser. However, we can run into performance issues when JavaScript code reads layout-specific properties like offsetHeight or getBoundingClientRect(). These reads are synchronous and force the browser to perform a reflow immediately — possibly too early in the frame lifecycle.
Another potential issue arises when we read a layout property and, independently, perform a write operation afterward. In such cases, it’s better to wait for the browser-scheduled reflow to avoid unnecessary reflows.
To help with these optimizations, afterNextRender and afterRenderEffect allow us to specify whether our code should read from or write to the DOM — helping Angular schedule things in the correct order.
Top comments (0)