Angular is an open-source, TypeScript-based framework for building web applications, maintained by a team at Google and released under the MIT license. Unlike libraries that cover only the view layer, Angular is a full platform: it ships components, templates, dependency injection, routing, forms, an HTTP client, testing utilities and a command-line toolchain as one coordinated set of packages.
Angular is used mainly for large single-page applications with long lifetimes and many developers, such as enterprise portals, internal tools and administration systems. It should not be confused with AngularJS, the older JavaScript framework of the same family, which used a different architecture and reached the end of its official support at the end of 2021.
How an Angular application is built
An Angular application is a tree of components, each combining a TypeScript class, an HTML template and scoped styles. The framework compiles templates ahead of time into efficient JavaScript instructions, so the browser does not parse template syntax at runtime.
| Building block | Role | Typical example |
|---|---|---|
| Component | UI unit with template, logic and styles | Product card, data table |
| Template syntax | Bindings, events and control flow in HTML | Conditional blocks and loops |
| Service | Reusable logic shared through injection | API client, authentication state |
| Dependency injection | Supplies dependencies by configuration | Swapping a real service for a mock |
| Router | Maps URLs to components, lazy loads routes | Account and settings sections |
| Signals | Fine-grained reactive state | Counters, derived totals, form state |
Dependency injection is the feature that most distinguishes Angular from lighter libraries. Components declare what they need, and hierarchical injectors decide which instance to provide, which makes it straightforward to replace a service in tests or to scope state to one part of the application.
Recent versions moved toward standalone components, which no longer require grouping into NgModules, a built-in control-flow syntax for conditions and loops, and signals as the primary reactivity model. These changes reduce boilerplate while keeping the framework’s structured approach.
The framework also includes a deferrable views feature, which wraps part of a template in a block that loads its code only when a condition is met, for example when the block enters the viewport. This brings code splitting down to the template level without manual dynamic imports.
Change detection and rendering options
Change detection is the process by which Angular updates the DOM when application state changes. Historically, the Zone.js library patched browser APIs such as timers and events so that Angular could rerun change detection after any asynchronous operation. This approach is convenient but can cause unnecessary checks in large component trees.
| Strategy | How updates are triggered | Best suited to |
|---|---|---|
| Default with Zone.js | Any async event checks the whole tree | Simple or legacy applications |
| OnPush | Only changed inputs, events or explicit marks | Large component trees |
| Signal-based updates | Components that read a changed signal | New code focused on precision |
| Zoneless mode | Signals and explicit notifications, no Zone.js | Applications seeking smaller bundles |
For rendering, Angular supports classic client-side rendering, server-side rendering (SSR) with hydration, and static prerendering of routes at build time. Newer releases add incremental hydration, where deferred parts of a page become interactive only when needed, which lowers the main-thread cost of startup.
Angular compared with other frontend frameworks
Angular, React, Vue.js and Svelte all build component-based interfaces, but they differ in how much they prescribe. Angular makes the most decisions for the team, which is its main strength and its main cost.
| Framework | Scope | Language default | Typical strength |
|---|---|---|---|
| Angular | Complete platform | TypeScript | Consistency in large teams |
| React | View library plus ecosystem | JavaScript or TypeScript | Flexibility and ecosystem size |
| Vue.js | Progressive framework | JavaScript or TypeScript | Gentle learning curve |
| Svelte | Compiler-based framework | JavaScript or TypeScript | Small runtime output |
With React, a team chooses its own router, state management and data-fetching tools, often through a meta-framework such as Next.js. With Angular, these pieces are official, versioned together and updated with automated migrations. The trade-off is a steeper learning curve: developers must learn TypeScript decorators, dependency injection, RxJS observables and the framework’s conventions.
When to choose Angular
Angular fits projects where long-term maintainability and uniform structure matter more than minimal initial size. The decision table below summarizes typical situations.
| Situation | Recommendation | Reason |
|---|---|---|
| Large enterprise application | Strong fit | Shared conventions across many teams |
| Complex forms and workflows | Strong fit | Mature reactive forms and validation |
| Content-heavy marketing site | Usually not ideal | Static or islands approaches load less code |
| Small widget on an existing page | Usually not ideal | Framework overhead exceeds the need |
| Team already skilled in TypeScript | Good fit | Lower onboarding cost |
The Angular team publishes a major version about every six months, and each major version receives about 18 months of support, including a long-term support phase. The Angular CLI generates code, runs builds and applies update schematics, which keeps upgrades predictable when teams move one major version at a time.
Common pitfalls with Angular
Most problems in Angular projects come from ignoring the framework’s performance model or postponing upgrades.
- Skipping lazy loading: putting every feature in the initial bundle slows the first load considerably.
- Unmanaged subscriptions: RxJS subscriptions that are never cleaned up cause memory leaks.
- Default change detection everywhere: large lists without OnPush or signals trigger excessive checks.
- Skipping major versions: jumping several versions at once makes automated migrations fail more often.
- Treating it as AngularJS: old tutorials and patterns do not apply to modern Angular.
A further source of trouble is mixing reactivity models without a plan. Many codebases now combine RxJS observables for streams such as HTTP responses with signals for local state. Clear conventions on where each model applies, and consistent use of the official interop helpers that convert between them, prevent duplicated state and subtle update bugs.
A plain-language summary
Angular is a ready-made toolkit for building websites that behave like applications, such as online banking or booking systems. It gives developers all the main parts in one box. Those parts include screens, navigation, forms and a way to talk to servers.
Think of it as a fully equipped kitchen rather than a set of separate gadgets. Everything matches and follows the same rules. It takes longer to learn. Yet large teams can work together more smoothly because everyone uses the same tools.
An example from practice
An insurance company replaces an aging internal claims system used by about 600 staff. The new application has dozens of screens, multi-step forms with complex validation and strict role-based access. Four development teams work on it in parallel, so the company chooses Angular for its shared structure.
Each business area becomes a lazily loaded route, so adjusters download only the screens they use. Services built on dependency injection handle authentication and API access, and tests swap them for mocks. Signals manage form and dashboard state with OnPush change detection throughout. Twice a year, the teams upgrade to the next major version with the CLI’s automated migrations, so the application stays current without large rewrites.