Angular Isn't Slow. Your Architecture Is.
Every few months, I come across a post saying:
"Angular is slow."
Honestly, I used to believe there was at least some truth to it.
Over the last few weeks, I spent a significant amount of time migrating a fairly large enterprise application from Angular 16 to Angular 21. Like most migrations, I expected dependency conflicts, build issues, and a few breaking changes.
I got all of those.
What I didn't expect was to question how I write Angular applications.
The migration made me realize something that I hadn't thought about before:
Angular isn't slow anymore.
Most of us are simply writing Angular 21 applications using patterns that were perfectly reasonable five or six years ago.
The framework has evolved much faster than many of our codebases.
Angular Has Changed More Than You Think
If the last Angular version you seriously explored was Angular 10 or 11, modern Angular might surprise you.
Today we have:
- ✅ Standalone Components
- ✅ Signals
- ✅ New template control flow (
@if,@for,@switch) - ✅ Deferred loading
- ✅ Faster builds with esbuild
- ✅ Better SSR and hydration
- ✅ Zoneless applications
- ✅ Functional dependency injection using
inject()
These aren't just quality-of-life improvements.
They fundamentally change how applications can be structured.
The problem is that many teams upgrade Angular every six months, but their architecture stays exactly the same.
The Framework Gets Blamed for Problems It Didn't Create
Whenever I hear someone say Angular is slow, I usually ask one question:
"What exactly is slow?"
Most of the time, the answers sound familiar.
- Initial page load
- Long build times
- Components taking forever to render
- UI freezing
- Huge bundle sizes
Those are real problems.
But after looking at enough enterprise applications, I've noticed they rarely come from Angular itself.
Instead, they usually come from things like:
- Components with thousands of lines of code
- Massive SharedModules importing everything
- Every feature loading on startup
- Too many unnecessary RxJS subscriptions
- Heavy third-party libraries
- Business logic living inside components
- Poor change detection strategies
Those problems would exist regardless of the framework.
Stop Writing Angular 21 Like It's Angular 10
One thing I noticed during migration was how many old habits I had carried forward simply because "that's how Angular projects are built."
It turns out many of those habits are no longer the recommended approach.
Standalone Components
When Standalone Components were first introduced, I thought they were just another way to avoid NgModules.
After using them throughout a migration, I completely changed my opinion.
Each component clearly declares what it depends on.
Features become easier to lazy load.
There's less boilerplate.
And perhaps most importantly, navigating the project becomes much easier.
Instead of jumping through multiple modules trying to understand where something is declared, everything is right where you'd expect it.
Small improvement.
Huge quality-of-life difference.
Signals Changed How I Think About State
For years, my default approach looked something like this:
Need reactive data? Create another Observable.
Now I find myself asking a different question.
Does this actually need to be an Observable?
A surprising amount of component state doesn't.
Loading indicators.
Selected items.
Counters.
Filters.
Simple UI state.
Signals handle these incredibly well while keeping components much easier to understand.
I'm definitely not saying RxJS is obsolete.
Far from it.
It's still the right tool for asynchronous streams, HTTP requests, websockets, and complex event flows.
But using RxJS for every piece of state now feels a bit like using a sledgehammer to hang a picture frame.
The New Template Syntax Is Better Than I Expected
I'll admit it.
When Angular announced the new control flow syntax, I didn't think it would make much difference.
I was wrong.
Instead of writing:
<div *ngIf="users.length">
<app-user-card
*ngFor="let user of users; trackBy: trackById"
[user]="user">
</app-user-card>
</div>
We can now write:
@if (users.length) {
@for (user of users; track user.id) {
<app-user-card [user]="user" />
}
}
It feels cleaner.
It's easier to read.
And because track becomes part of the syntax, it's easier to write performant lists by default.
Build Speed Matters More Than We Admit
One of my favourite improvements had nothing to do with runtime performance.
It was the build process.
Moving to Angular's modern build system with esbuild made local development noticeably faster.
The interesting thing about faster builds isn't just saving a few seconds.
When builds are quicker:
- You experiment more.
- You refactor more confidently.
- You test ideas more often.
- You spend less time waiting.
Developer experience matters.
Over hundreds of builds each month, those small improvements add up.
Performance Isn't Just About Rendering
When developers say an application is slow, they're usually describing the entire experience.
Questions like:
- How quickly does the application start?
- How responsive does the UI feel?
- How long do builds take?
- How much JavaScript are users downloading?
- How much code executes before the first interaction?
Angular 21 improves many of these areas.
But if we're still shipping huge bundles, importing entire libraries for one utility function, or putting thousands of lines of business logic into a single component, the framework can't solve those problems for us.
Architecture still matters.
Things I'd Review in Any Angular Project Today
If I joined a new Angular project tomorrow, these are some of the first things I'd look at.
- Are we still relying on huge SharedModules?
- Could some component state become Signals instead of Observables?
- Are routes properly lazy loaded?
- Are components trying to do too much?
- Are we importing libraries we barely use?
- Are we using
trackwith@for? - Are Standalone Components being used consistently?
- Can features be split into smaller, independent pieces?
None of these changes are revolutionary.
But together they make projects easier to maintain, easier to scale, and often noticeably faster.
My Biggest Takeaway
The biggest lesson from this migration wasn't learning a new Angular feature.
It was realizing how easy it is to upgrade the framework without upgrading our thinking.
Installing Angular 21 takes a few commands.
Writing applications that actually take advantage of Angular 21 takes a different mindset.
Sometimes the biggest performance improvement isn't a new API.
It's letting go of patterns we've been carrying around for years.
Final Thoughts
Angular has evolved a lot.
The tooling is faster.
The APIs are cleaner.
The developer experience is better than it's ever been.
The question isn't whether Angular is fast enough anymore.
The better question is:
Are we building applications that take advantage of what modern Angular offers?
I'd genuinely love to hear what others think.
If you've migrated to Angular 20 or 21 recently, what architectural change made the biggest difference in your project?
Thanks for reading! If you enjoyed this article or have a different perspective, let's discuss it in the comments. I always enjoy hearing how other teams are approaching modern Angular.
Top comments (0)