Angular - Google's Opinionated TypeScript Framework

So you've heard Angular is opinionated.

What does that actually mean? Angular is what happens when Google engineers get tired of every React project having 47 different ways to handle routing and decide to just pick one for you.

It's a complete framework that makes architectural decisions so you don't have to argue about them in code review.

The Good:

Everything you need is included. No analysis paralysis about which router, which form library, which HTTP client to use. Angular 20 (released May 29, 2025) comes with batteries included

• routing, forms, HTTP client, testing framework, everything.

The Bad:

Steeper learning curve than React/Vue, and your bundle size will be larger.

Oh, and if you're on Windows, the Angular CLI will eat your PATH environment variable if it gets too long (2048 character limit). Learned that one after a 3-hour debugging session. But once you know Angular, you know Angular

• no ecosystem churn every 6 months.

The Reality: If you're building anything enterprise-scale, Angular's component architecture will save your ass when the project grows beyond 5 components.

I've seen React codebases turn into spaghetti nightmares at scale. Angular's dependency injection and structured approach prevents that.

The TypeScript Reality Check

Angular forces TypeScript on you from day one.

This pisses off Java

Script purists, but it catches dumb mistakes before they hit production. You'll spend your first week cursing the compiler, then realize it saved you from shipping undefined is not a function errors to users.

The tooling is solid

• VS Code autocomplete actually works, refactoring doesn't break everything, and the Angular Language Service catches template errors at compile time.

Try doing that with JSX.

What Actually Matters in Angular 20

The latest version fixes stuff that was actually broken:

• Zoneless change detection:

Finally ditching Zone.js, which was causing weird async bugs nobody understood

• Signals everywhere:

State management that doesn't require a PhD to understand

• Standalone components:

No more NgModule hell for simple apps

• Better dev tools: Chrome DevTools integration that shows Angular-specific performance data

Real talk: 90% developer satisfaction doesn't mean much when the survey only includes people who haven't jumped ship yet.

Survivorship bias is real. But the core complaints (bundle size, complexity) are being addressed.

When Angular Makes Sense

Use Angular if:

• You're building something complex that will live for more than 6 months
• Your team prefers structure over flexibility
• You need built-in enterprise features (i18n, accessibility, testing)
• You're tired of choosing between 15 state management libraries

Don't use Angular if:

• You're building a marketing site that needs to load in 200ms
• You have a small team that values moving fast over maintainability
• You enjoy the React ecosystem's constant churn

Now that you understand Angular's value proposition, here's how it actually works. Angular's architecture makes sense after you've built 3-4 components. Before that, it feels like overkill for a simple todo app. Here's what actually matters and where you'll get stuck.

Components: Custom HTML Tags with TypeScript Attached

Components are basically custom HTML tags with TypeScript logic. Standalone components are great until you forget to import CommonModule and wonder why *ngIf doesn't work.

@Component({
  selector: 'user-profile',
  standalone: true,
  imports: [CommonModule], // Forget this = broken templates
  template: `
    <h2>{{ user.name }}</h2>
    <div *ngIf="user.isActive">Active User</div>
  `
})
export class UserProfileComponent {
  user = { name: 'John Doe', isActive: true };
}

Reality Check: You'll spend 30 minutes debugging why your template isn't updating, only to realize you forgot CommonModule. Every Angular developer has done this.

Signals: Finally, State Management That Makes Sense

Angular Signals are awesome for simple state management. But if you're doing complex async stuff, you'll still need RxJS. Signals don't replace observables - they complement them.

// This works great
count = signal(0);
doubleCount = computed(() => this.count() * 2);

// This gets messy fast with complex async operations
// You'll still reach for RxJS

The Gotcha: Signals are synchronous. For HTTP requests and complex async flows, stick with observables. Don't try to force everything into signals.

Dependency Injection: Powerful When You Get It

DI makes sense after building a few services. Before that, it feels like unnecessary complexity. The inject() function is cleaner than constructor injection, but good luck debugging circular dependencies.

@Component({})
export class DataComponent {
  private http = inject(HttpClient);
  private userService = inject(UserService); // Could create circular deps
}

What You'll Hit: ERROR: Circular dependency detected: UserService -> AuthService -> UserService at build time. Usually happens when AuthService tries to check permissions by calling UserService methods. Fix: extract the shared logic to a third service, or inject HttpClient directly instead of going through services. Took me 4 hours to figure this out the first time.

Routing: Comprehensive but Complicated

Angular Router handles everything - lazy loading, guards, resolvers. But the learning curve is steep. You'll spend hours figuring out why your route guard isn't working.

// This route config will break your brain initially
const routes = [
  {
    path: 'users/:id',
    component: UserComponent,
    canActivate: [AuthGuard],
    resolve: { user: UserResolver },
    loadChildren: () => import('./user/user.module').then(m => m.UserModule)
  }
];

Common Frustration: Route guards run in specific order (canActivate → canMatch → canLoad), and if one fails silently, you'll waste 2 hours wondering why your component never loads. The router just... doesn't navigate. No error. Nothing in console. Just sits there laughing at you.

Forms: Two Ways to Do Everything

Angular gives you two form approaches because one wasn't confusing enough:

• Reactive Forms: For when you like writing form logic in TypeScript
• Template-driven: For when you want to pretend forms are simple

// Reactive forms = boilerplate hell but at least it fucking works
userForm = new FormGroup({
  name: new FormControl('', [Validators.required, Validators.minLength(3)]),
  email: new FormControl('', [Validators.required, Validators.email])
});

The Reality: You'll use reactive forms for complex stuff, template-driven for simple inputs, and constantly forget which validators apply where.

What Actually Trips Up New Developers

1. Change Detection: Your component isn't updating? You probably mutated an array directly instead of creating a new one. I once spent 3 hours debugging why a todo list wouldn't update after todos.push(newTodo). Had to change it to todos = [...todos, newTodo]. Angular doesn't detect mutations, only reassignments.
2. Template Syntax: {{}} for interpolation, [] for property binding, () for events. Mix them up = runtime errors.
3. Async Pipe: *ngFor="item of items$ | async" is magic until it breaks and you don't understand observables. Spent an entire day wondering why my list was empty, turns out I was returning a Promise instead of an Observable from my service. async pipe works with both, but the behavior is different and the errors are cryptic.
4. Lifecycle Hooks: ngOnInit vs constructor vs ngAfterViewInit - you'll use the wrong one at least 10 times.