During a recent podcast, Minko Gechev — Lead and manager for Angular developer relations — offered a detailed look at where Angular is headed. The conversation covered a wide range of upcoming changes and priorities within the framework.
Hydration API
The Angular Lead discussed the upcoming hydration feature, which is designed to enhance server-side rendering and boost performance. A key focus is now on partial hydration, which promises quicker rendering for applications.
The aim is to achieve stronger SSR support and ensure smoother transitions when moving between server-rendered and client-rendered views.
Introducing DestroyRef
One of the most significant updates Minko highlighted was DestroyRef. This addition lets developers trigger ngOnDestroy with greater flexibility and tie it into various stages of a component’s lifecycle.
class ExampleComponent {
constructor() {
inject(DestroyRef).onDestroy(() => {
// do something when the component is destroyed
})
}
}
This kind of control wasn’t possible before; the cleanup logic had to live directly inside the ngOnDestroy method. With DestroyRef, interoperability with libraries such as RxJS improves, streamlining development in Angular.
Angular Material Libraries and Design Tokens
Minko also touched on how design tokens, especially within Material 3, are influencing Angular app development. These tokens give developers more freedom when tailoring existing Material components.
Google’s Material team is committed to keeping these tokens stable, so developers can build precisely customized components without worrying about constant adjustments.
Flattening the Angular Learning Path
Making Angular easier to learn is a top priority for the team. Minko walked through several gradual improvements meant to lower the barrier for newcomers and simplify day-to-day work.
He acknowledged that RxJS can be daunting for developers just starting out and that the Angular Team wants to accommodate both camps. Those who prefer RxJS can keep using it; those who don’t can opt for Signals. A combination of the two? Also perfectly acceptable.
Here’s an example of interop:
const counter: Signal<number> = toSignal(counter$);
const counter: Observable<number> = toObservable(mySignal);
The longer-term objective is to gradually reduce how much of the core framework depends on RxJS. Will this satisfy both newcomers and seasoned developers? Judging by the discussions in the RFCs — some experienced developers are quite worried about the direction being taken.
Standalone Components
Standalone components are a key first step in making Angular less complex. With this feature, understanding NgModule and scoping becomes optional for those building standalone apps.
@Component({
selector: 'app-root',
templateUrl: './app.component.html',
standalone: true,
styleUrls: ['./app.component.scss']
})
export class AppComponent {}
Further refinements are also in the works for how standalone components work today.
Simplifying Component Authoring Experience
Minko noted that the Angular Team is exploring ways to make the component, directive, and pipe decorators optional. The goal is to streamline how components are authored and cut down on unnecessary complexity.
Inputs and outputs could become simpler and more functional as a result.
Angular CLI Simplification
The CLI is being streamlined to carry less conceptual baggage, and the project structure will be improved so developers can move through Angular projects with greater ease.
Improved Documentation and Learning Experience
The Angular Team intends to revamp its tutorials to make them more interactive and easier to follow, helping developers pick up Angular more quickly and with more enjoyment.
That would be a major upgrade compared to the current state of Angular’s documentation.
All in all, Angular’s trajectory looks encouraging, with a clear emphasis on making the framework more approachable and easier to pick up. DestroyRef, design tokens, and a smoother learning curve are just a few of the major updates that will steer the framework in the coming releases.
At the same time, this path may push Angular closer to a more functional component style and toward its closest rivals — React & Vue.
That’s a quick look at the highlights — I’d suggest checking out the full podcast for more context.
I’ve previously covered what’s going on with Sub-RFC3 and Sub-RFC4 — with everything taking shape, are you optimistic about Angular’s future?
Or are you concerned that these changes might strip away the framework’s distinctive character?
This is the final opportunity to weigh in on the Signals RFC! — The Angular Team will close it on Monday, April 24! — check it out here.
I hope you liked my article!
If you enjoyed this, you may be interested in what I do on Twitter. I host live Twitter Spaces focused on Angular with GDEs and other industry professionals. You can tune in live, ask questions, or check out short replays afterward.
If that sounds good, feel free to follow me on Twitter @DanielGlejzner — it would be greatly appreciated. Thanks!











