During a recent podcast, Minko Gechev, the Lead and manager for Angular developer relations, shared some valuable insights into the future of Angular and its planned developments. In this article, we will go over the key takeaways from the interview, focusing on the framework’s future direction.

Hydration API

Hydration API is a new feature introduced by Angular that aids in server-side rendering and enhances performance. Angular is now focusing on partial hydration to result in faster rendering times for applications. The objective is to provide better server-side rendering support and smoother transitions between server-rendered and client-rendered content.

Introducing DestroyRef

One of the most notable enhancements discussed by Minko is the introduction of DestroyRef. This feature enables developers to invoke the ngOnDestroy hook more flexibly and integrate it with various parts of the component’s lifecycle.

Here’s an example code snippet:

class ExampleComponent {
  constructor() {
    inject(DestroyRef).onDestroy(() => {
      // do something when the component is destroyed
    })
  }
}

Previously, developers had to place the ngOnDestroy code directly in the method itself, but DestroyRef will improve integration with libraries like RxJS, making Angular development more efficient.

Angular Material Libraries and Design Tokens

Minko highlighted the impact of design tokens on Angular app development, particularly within Material 3. Design tokens provide developers with greater flexibility for customizing existing Material components. The Material team at Google will ensure that these tokens remain stable, allowing developers to create finely-tuned components without worrying about frequent changes.

Flattening the Angular Learning Path

Simplifying the Angular learning path is a priority for the Angular Team. Minko outlined several incremental improvements aimed at making it easier for developers to learn and work with Angular.

He says that RxJS is overwhelming for new developers, and the Angular Team aims to satisfy both sides. If you want to use RxJS, go for it. If you don’t want to use it, go with Signals. Mix of both? Feel free.

Here’s an example of interop:

const counter: Signal<number> = toSignal(counter$);
const counter: Observable<number> = toObservable(mySignal);

Over time, the plan is to reduce the RxJS involvement in core parts of the framework. However, there have been recent discussions in RFCs, and some veteran developers have major concerns about the approach for the future.

Standalone Components

The introduction of standalone components is a foundational step towards simplifying Angular. This feature will make learning about NgModule and scoping optional for developers working on standalone apps.

Here’s an example code snippet:

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  standalone: true,
  styleUrls: ['./app.component.scss']
})
export class AppComponent {}

There are also improvements expected for how standalone components are handled today.

Simplifying Component Authoring Experience

Minko briefly mentioned that the Angular Team is considering making component, directives, and pipe decorators optional. The aim would be to further simplify the component authoring experience and reduce complexity. This will result in a simpler, more functional-based approach for creating inputs and outputs.

Improved Documentation and Learning Experience

The Angular Team will focus on creating more engaging and digestible tutorials, helping developers learn Angular more efficiently and enjoyably. This would be a giant help and improvement over the current shape of Angular documentation available today.

The future of Angular looks promising, with a focus on simplification and improved learning experiences for developers. The introduction of DestroyRef, design tokens, and the flattening of the Angular learning path are just a few of the key developments that will shape the framework’s direction moving forward. However, some veteran developers have expressed concerns about the changes, particularly the reduced involvement of RxJS in core parts of the framework. The Angular team will need to balance the needs of both new and existing developers as they continue to improve the framework.