Future of Angular
One of the biggest benefits of Angular is that you can count on major releases every 6 months. However, with a regular cadence comes the pressure to release meaningful and splashy updates with every major release. We can probably blame Google for creating this pressure. If you’re not constantly producing, you’re out. This has an unfortunate side effect of new features being released in preview or an unfinished state. While an argument can be made that releasing upcoming features in preview allows for feedback to be collected from the developer community, no guarantees are made that performance regressions will not be introduced.
If your team is not consuming every bit of Angular news coming out regularly, you may miss these nuances and roll out code into production that negatively impacts your business, potentially impacting revenue. For example, some users have noticed performance regressions in Angular 16, and the Angular team knew about this and fixed it in Angular 17, but this posture puts businesses who’ve taken up the new version at risk.
The ambitious Angular Elements feature best exemplifies another aspect of this. Circa Angular 9, a big deal was made when announcing web component support for Angular. The promise was that you could create universally reusable components using your favorite framework. The team highlighted the great challenge of shipping a pared-down version of Angular along with the component – reducing the framework size from 150 KB to only a few KB. Instead of focusing on finalizing this feature, and despite making great incremental process, the team has found the task too daunting. So the team has moved on to different ideas to tackle this problem. But even those new ideas are being rushed and rolled out in a preview state, e.g., Angular signals adding to the pile of unfinished work in production software. In Angular 17, signals are partially out of preview and have the potential to transform how Angular apps are built in the future with the implementation of signal-based components. Signals do not easily leak memory compared to RxJS’s leaky subscription concept. Signals can also work with async/await calls, avoiding many unnatural uses of reactive coding with RxJS. The stable delivery of all these features is probably due in Angular 19.
Find out up-to-date information about upcoming and in-preview features at https://angular.dev/roadmap.
A large Angular application suffers from crippling performance issues just like Angular.js did, except the goalposts around the definition of large have moved significantly. The major trouble here is that it’s impossible to resolve these performance issues, at least not without significant engineering investment that leaves you digging under the hood of the Angular rendering engine.
Further, in 2023, by leveraging ES2022 features, it is possible to build reactive and interactive web applications using pure JavaScript. Angular signals expose these ES2022 features to enable fine-grained reactivity by replacing Zone.js with native JavaScript. This means that only the parts of the DOM that need to get updated are updated, significantly reducing render times. This is a topic I further explore in Chapter 3, Architecting an Enterprise App. Combining these changes results in a more optimized change detection cycle, resulting in smoother FPS.
Every release of Angular seeks to improve Time-to-Interactive (TTI) for modern browsers. In the past, this meant improving bundle sizes, introducing lazy loading of modules, and now individual components. Angular now supports Server-side Rendering (SSR) with non-destructive hydration. This means that a server can compute the DOM of a view and transfer it to the client, and the client can update the DOM displayed to the user without completely replacing it.
Angular is also moving away from Jasmine to Jest. Jasmine has always been a great unit-testing framework. However, making it work in a web application context always requires a lot of configuration and additional tools like Karma to execute the tests and get coverage reports. Jest includes all these features. The support is currently experimental, and it’s unclear whether Vitest will be a better option than Jest. Angular is moving away from webpack to esbuild, which is about 40x faster than webpack. Once again, it is only available as a (developer) preview.
As you can see, some of the most exciting things happening in Angular are in preview features. The ground truth is that teams are heads down, working on delivering features for their projects and trying their best to keep up with all the latest changes. It’s tough enough to keep updating dependencies continually; big changes in the mental model of the framework, combined with performance issues, risk losing the confidence of developers and businesses alike. Trust is hard to build and easy to lose.
The reality is the Angular team is doing great work, and the framework is making the necessary changes to evolve and meet ever-growing expectations. It bears repeating Google mandates that the 2,000+ Angular projects they have must all be on the same version of Angular. This means that every new update to Angular is well-tested, and there are no backward compatibility surprises.
Angular remains an exciting, agile, and capable framework. My motivation is to inform you of where the land mines are. I hope you are as excited as I am about the state of modern web development and the future possibilities it unlocks. Buckle up your seatbelt, Dorothy, ‘cause Kansas is going bye-bye.
