Pick any modern web team and you can predict a lot about their stack just from the framework on the homepage. React shops are usually a swarm of small libraries glued together with conventions the team invented. Angular shops mostly look the same as each other. That is not a coincidence, and it is not an accident.

This lesson opens the Angular tutorial with the question every reader actually has on day one: what is this thing, and why would I pick it? We will pin down what Angular is, what it isn't, where it sits next to React and Vue, and the concrete signals that tell you Angular is the right tool for a project — or the wrong one. By the end you will have a fair frame for the rest of the tutorial, free of marketing copy from either side of the framework wars.

Angular is a framework, not a library #

The first distinction is the most important one, because it explains every other decision the Angular team has made for the last decade.

React is a UI library. It renders components, manages a virtual DOM, and goes home. Routing, forms, HTTP, state management, build tooling — all picked à la carte from a thousand-package ecosystem. Two React apps can share almost nothing in common.

Angular is the other shape. The Angular CLI scaffolds your project, the build pipeline is shipped with the framework, the router is the official router, the HTTP client is the official HTTP client, and the dependency-injection system is the way you wire services together. There is one idiomatic answer to most architectural questions, and it is the answer the Angular team wrote.

This is what people mean when they call Angular opinionated or batteries-included. It is a Volkswagen Beetle in a world of Lego kits — fewer choices, more consistency.

What ships in the box #

When you install the Angular CLI and run ng new, you get a working app with the following pieces, none of which you have to install separately or wire up yourself:

• Component framework — declarative templates, lifecycle, change detection.
• Signals (since v17) — fine-grained reactivity primitive, replacing most everyday RxJS use.
• Router — code-split routes, guards, resolvers, view transitions.
• HTTP client — HttpClient, interceptors, testing utilities.
• Forms — both template-driven and reactive, plus the new signal forms (v22).
• Build tooling — esbuild-based production builds, dev server with HMR.
• SSR & hydration — provideServerRendering() for server-rendered apps with non-destructive hydration.
• Testing — Vitest by default in v21 (Karma is gone), with TestBed for component tests.
• Internationalization, accessibility, animations — first-party APIs.
• Dev tools — Angular DevTools extension, Language Service for IDE intellisense.
• ng mcp (v21) — official MCP server for AI assistants.

The reason this matters in practice: in a typical Angular team, the answer to a new requirement is almost always already in the box. You do not pick between five competing routers or three competing HTTP libraries. You learn the Angular router, the Angular HttpClient, the Angular forms API, and that knowledge transfers to every other Angular codebase you ever touch.

Where Angular sits next to React and Vue #

A side-by-side comparison, kept honest:

There is no winner row in that table. Angular trades discoverability for consistency, React trades consistency for flexibility, Vue tries to land in the middle. Each is the right answer for some shape of project.

When Angular is the right call #

The argument for Angular gets stronger as the project gets longer-lived and the team gets bigger:

• Enterprise applications where five developers will rotate through the codebase over four years.
• Internal tools and admin dashboards built and maintained by IT teams who do not write throwaway code.
• Multi-team monorepos where every team needs to read every other team's components without learning a new flavor of React.
• Greenfield projects with a TypeScript-first culture where types are not negotiated.
• Applications with non-trivial forms — financial, healthcare, government — where validation, accessibility, and reactive state matter more than visual flair.
• Teams that want one framework to cover web + mobile + SSR without separately adopting React Native + Next.js + a state library.

The common thread is long-lived code and plural authors. Angular pays its onboarding tax up front and earns it back over years of consistent code.

When Angular is the wrong call #

The honest list, no flinching:

• Throwaway prototypes or landing pages. Picking Angular for a marketing site is a category error. Use plain HTML, Astro, or 11ty.
• "Move fast, refactor later" startups at the first-product stage where the team is one or two people optimizing for shipping, not architecture.
• Teams already deep in the React ecosystem — switching costs are real and the React reach is huge. Sometimes the right framework is the one your team already ships in.
• Apps where the UI is the differentiator and animation is everything. Angular can do it; React + Framer Motion is more popular for that surface.
• Static content sites. A blog or docs site does not need a framework that ships a router and an HTTP client; it needs a static site generator.
• You hate dependency injection. Angular's DI is a feature, not a wart, but it is also non-negotiable. If you reflexively reach for global singletons, Angular will feel hostile.

The pattern: Angular is for applications, not pages, and for teams, not one developer's side project. When those constraints do not match the project, picking Angular is just expensive React.

What changed by 2026: the v21 / v22 reset #

If you tried Angular five years ago and bounced off, the framework you remember is not the framework you would install today. The last three major versions have effectively rewritten the developer experience without breaking apps:

• NgModules are gone for new apps. Components are standalone by default — no more boilerplate app.module.ts to register everything in.
• Signals replaced most everyday RxJS. You no longer reach for BehaviorSubject + async pipe to render a counter. You reach for signal(0) and put it in the template.
• Zoneless is the default in v21. The framework no longer monkey-patches setTimeout and Promises to detect changes. Bundles shrunk, performance went up.
• Vitest replaced Karma in v21. Tests run in seconds, not minutes.
• Signal forms arrived in v21/v22. Forms are now declared as signals with reactive validation — no more valueChanges + takeUntil(this.destroy$) plumbing.
• @if @for @switch control flow replaced *ngIf and *ngFor — better type narrowing, better performance, far better ergonomics.
• Selectorless components landed in v22. Components import directly into templates — no string-selector indirection.
• ng mcp shipped — Angular's official Model Context Protocol server, the first major framework to ship one.

If you read older tutorials, you will see NgModule, *ngIf, BehaviorSubject, and Karma everywhere. This tutorial does not. We teach modern Angular as it actually exists in 2026, and call out legacy patterns only when you might encounter them in existing code.

A taste of an Angular component #

This tutorial walks through every piece of this code over the next dozen lessons, so do not expect to understand every line yet — just notice the shape:

import { Component, signal, computed } from '@angular/core';

@Component({
  selector: 'app-counter',
  template: `
    <button (click)="increment()">Count: {{ count() }}</button>
    @if (count() >= 10) {
      <p>You hit ten. Nice.</p>
    }
    <p>Double: {{ double() }}</p>
  `,
})
export class CounterComponent {
  count = signal(0);
  double = computed(() => this.count() * 2);

  increment() {
    this.count.update(n => n + 1);
  }
}

A few things are worth noticing even at this stage:

• The component is a class with TypeScript decorators — that is Angular's signature shape.
• The template lives inside the class (or in a sibling .html file). It is HTML with extra control-flow syntax (@if).
• State is a signal — count is a function-like value you call with count() to read, and count.update(fn) to write.
• computed() derives reactive state from other signals — no manual subscription, no pipe(map(...)).
• No NgModule. No @Input() decorator wrapping anything (we will get to input() signals in lesson 2.4). No imports of BrowserModule. The component just is.

This is what modern Angular looks like. The rest of the tutorial earns each of these primitives by name.

What's next #

With the framing in place, the next lesson is hands-on: we install the Angular CLI, run ng new, and walk through every file the scaffold creates — what each does, why it is there, and which ones you will touch daily. By the end of lesson 1.2 you will have a running Angular app on localhost:4200.

After that, Module 1 takes you through dependency injection, TypeScript essentials, the build pipeline, and the bootstrap flow. Module 2 spends the most time of any module on components, templates, pipes, and directives — the everyday surface you will touch on every screen of every app.

Try it yourself #

If you want a one-minute sanity check before lesson 1.2, you can ask any modern AI assistant (with Angular's official MCP server wired up) to confirm the framework's current shape:

That is the shape of the framework you are about to learn. See you in lesson 1.2.