The Angular Renaissance: Why Frontend Devs Should Revisit It
Frontend developer Alyssa Nicoll has a message for other frontend developers: Angular is experiencing a renaissance moment and it’s time to revisit this JavaScript framework.
Nicoll is the host of the Angular Air podcast and a senior developer advocate for Progress, where her duties include working with the Google Angular team. The TypeScript-based framework has changed significantly since 2015 and continues to expand its features, Nicoll said. That’s when Google rewrote AngularJS to create a completely different framework, Angular 2+. Then, for a long time, the Angular team was rewriting its base view engine called Ivy. With that now finished, the Angular team has unleashed upgrades and new features that it had previously put off, she said. As a result, Angular is becoming more friendly to all users.
“That’s why I relate it to the Renaissance, because not only is there just a bunch of activity and freshness and creativity coming in, but also it’s geared towards the developer experience,” Nicoll said. “A big part of the [Renaissance] movement was this humanist aspect of human growth and human potential. This movement in Angular focuses on the developer experience and the human potential to use Angular and make it more friendly to all users.”
That may be a hard sell. Numbers from a 2023 Stack Overflow survey show framework use overall is declining and in particular, Angular use in the past year fell 24%. Meanwhile, Svelte and Deno use increased by approximately 62 and 61% respectively. Angular controls about 18% of the framework “market,” while React still leads with nearly 41% adoption.
Adoption decline is part of what’s driving the change.
“The Angular team … is very conscious of this developer experience as we’re on onboarding new developers, because if we don’t have an influx of new developers, our community will slowly wither,” Nicoll said.
There are three key ways the framework is evolving that make it worth revisiting, Nicoll said.
1. Moving off Modules
Angular is unique among JavaScript frameworks in that the smallest chunk of code is not a component, but a module. Modules are wrappers that hold things like dependencies and shared functionality or even routing, Nicoll explained.
The movement away from modules may cause a struggle among “Angularites” who are accustomed to them, but it will make it easier for other developers to understand the framework, she said.
“Even people who have been doing Angular for a long time, once they stop using modules, they start to see the potential going forward of what our framework could look like,” she said. “It makes us […] more compatible to other JavaScript developers. If they need to quickly jump on an Angular project — because there’s a lot of teams that have an Angular project, or a React project or a Vue project — it makes it easier for people to grok our framework, because the base pieces, the Legos, look the same.”
For Angular veterans, Nicoll recommended against a rip-and-replace approach for in-production applications.
“You can remove your application module, the base one that bootstraps the whole app. [But] I would not recommend it, because the community itself, I don’t believe, is supporting that yet,” she cautioned. “If you do that, a lot of your dependencies will probably start screaming at you, because they can no longer find your application because they depend on that base module to tell them who and what this app is, and ‘how do I fit into this world.’”
The tools and dependencies to support this base structure of Angular applications are still evolving, she added, and are just not “there” yet.
“I’d say absolutely go and remove the modules from your components or make new components or pipes without them, or directives, but maybe, maybe hang off a bit in production applications with removing your base module, unless you’re very, very sure of all the dependencies that you have and how they integrate with your application,” she said.
2. Adding Signals to Angular
Angular is adding signals, giving it a “built-in primitive for reactivity,” Nicoll said. Signals will allow developers to easily manage and respond to changes in their applications. It has the potential to revolutionize the way developers approach reactive programming and make it more accessible to a wider range of developers, she contended.
“React and a lot of other frameworks, they have this concept [of signals] even on the .Net side.” Nicoll said. “This is in a way Angular catching up and also kind of making it cooler.”
A signal is an object that has a value and can be observed for changes. They are similar to React state, but according to Google Bard, offer a few key advantages:
- Signals can be shared between components without having to pass them down as props.
- Signals are only updated when they are needed, which can improve performance for large applications.
- Signals can be used to create complex state management patterns, such as Redux and MobX.
Currently, Angular offers observables for reactivity, combining it with on-push. While it works, there’s a cost, she’s said.
“The cost of using observables and using on push, when you come down to it, is zone.js — and a lot of Angular developers at this point will kind of make a throwing up face when you mentioned zone.js, or maybe like cross themselves — and change detection,” she said. “A built-in reactive primitive like signals does not have that cost.”
That change detection, as it’s now known, probably won’t exist in the future of Angular, she added, which will translate into faster load times, a quicker application, and potentially even quicker development, she said.
3. Control Flow
The proposed new control flow syntax is “heavily inspired by Svelte’s control flow, as well as the Mustache templating language,” Nicoll explained in a presentation on the topic she shared with The New Stack. “Think inline ifs, elses, switch statements, and defers.”
Control flow allows if and else statements to be put inside a template, so that developers can essentially load things or even defer the loading of things (like images) until the user is going to need it or is scrolling towards it, she explained.
“All of these things to make a better […] user experience on the other end of an Angular application,” she said. “And all of it, every single thing that I’ve mentioned, is opt-in; they’re not forcing you to change anything about the way that you do Angular, and nothing will break. And I think that’s a very important promise they intend to continue keeping for the Angular community.”
