DEV Community

Cover image for Angular's evolution: Is a Decorator-free future planned?
little chaosmonster
little chaosmonster

Posted on

Angular's evolution: Is a Decorator-free future planned?

As someone keenly interested in the Angular framework, I recently found myself intrigued by its latest changes. Reviewing the latest RFCs for built-in control flow and deferred loading, I noticed a subtle but significant trend: Angular is moving away from TypeScript decorators. I'll share my observations and thoughts on this development in this post.

A spark of realization

Even though the new Angular RFC - Built-In Control Flow does not directly contribute to the reduction of decorators, it did spark a thought in me. As I reviewed the RFC alongside the Angular Signals RFC, I realized that the Angular team seems to have a (hidden) agenda to minimize decorators.

The shift in Angular Signals

One of the most notable changes was the drop of the @Input decorator in favor of the input() function call when the Angular team introduced the new signals. This move was particularly striking as someone who appreciates decorators for their reduced cognitive load and less visual clutter.

The Decline of Decorators in Angular

Angular's effort to replace decorators with functions and other constructs isn't only visible with signals. For example, the introduction of standalone components eliminates the need for NgModules and their associated decorators without introducing new ones. This systematic phasing out begs the question: Is Angular preparing to become decorator-free?

The decorator's dilemma

The TypeScript decorators were experimental and, importantly, are not in line with the (years later) proposed JavaScript decorators. Given TypeScript's shift towards more closely following the evolution of JavaScript, it's plausible that TypeScript will eventually drop support for its current experimental decorator implementation.

Historically, decorators have been central in Angular (and frameworks like Nest.js) for annotations, compiler configurations, etc.
(While rewriting Angular 2, the team back then was even considering introducing a new "language add-on" called AtScript).
The move away from decorators indicates that Angular might be preparing for a future where these are either aligned with JavaScript decorator specs or no decorators at all (I do not know which one I would prefer at this point).

The Ripple Effect and the Future

While Angular is adapting proactively, it's intriguing to ponder how this might impact other frameworks like Nest.js that heavily rely on decorators. Additionally, how the Angular community and ecosystem adapt to these changes remains to be seen.

Concluding Thoughts

Angular's gradual distancing from TypeScript decorators seems like a strategic move to stay aligned with the evolving web standards and possibly pave the way for a more streamlined framework.

This article is based on observations and purely speculation. We have yet to learn the actual plans from the Angular team or any other teams.

What are your thoughts on Angular's evolution and the possible phasing out of decorators? Share your opinions in the comments below!

cover image: from unsplash by Ferenc Almasi

Top comments (0)