Web & Backend
Angular
Angular is a complete frontend framework maintained by Google and built on TypeScript, shipping routing, dependency injection, form handling, and an HTTP client as first-party parts of the framework rather than separate libraries a team chooses on its own. It structures an app as a tree of components, each with its own template, styles, and class, using Angular's own HTML-based template syntax rather than JSX. Angular 2 (2016) was a ground-up rewrite of the original AngularJS (1.x) and shares almost nothing with it but the name — a genuinely common source of confusion. More recently, Angular has been moving from Zone.js-based change detection and NgModules toward a signals-based reactivity model and standalone components, narrowing some of its historical complexity.
Why it matters
- It's a common default at large, team-heavy frontend organizations
- Its built-in conventions — one way to route, one way to build a form, one way to inject a service — matter most where consistency across many contributors and codebases outweighs the flexibility of picking your own libraries.
- TypeScript isn't optional the way it is with React
- Angular is written, documented, and error-messaged as a TypeScript-first framework; you can technically write plain JavaScript against it, but the framework itself assumes types are present.
- It bundles what most React projects have to assemble themselves
- Routing, an HTTP client, form validation, and dependency injection all ship with Angular, instead of being separate ecosystem decisions like React Router, a fetch wrapper, and a state-management library.
- It has an active, multi-year migration story teams have to plan around
- The shift from NgModules to standalone components and from Zone.js-based change detection to signals didn't happen for free between versions — existing Angular codebases have had to deliberately adopt each change.
Components and templates
An Angular component pairs a TypeScript class with an HTML template and (usually) its own stylesheet, declared with an @Component decorator. Templates use Angular's own syntax — property bindings, event bindings, and, since Angular 17, a built-in control-flow syntax (@if, @for, @switch) that replaced the older *ngIf/*ngFor structural directives for new code. This is a real syntactic departure from React's JSX, where control flow is just JavaScript.
@Component({
selector: "app-order-status",
standalone: true,
template: `
@if (order(); as o) {
<p>Status: {{ o.status }}</p>
} @else {
<p>Loading...</p>
}
`,
})
export class OrderStatusComponent {
order = signal<Order | null>(null);
constructor(private http: HttpClient) {
this.http.get<Order>("/api/orders/42").subscribe((o) => this.order.set(o));
}
}Change detection: Zone.js, then signals
Historically, Angular used Zone.js to patch async browser APIs so it could automatically detect when something might have changed and re-check the component tree. That works but re-checks more than necessary by default, which is why the OnPush change-detection strategy exists as a manual optimization. Signals, added more recently, are a fine-grained reactive primitive: a component can depend on a signal directly and only re-render when that specific value changes, which is the direction Angular is moving toward for both performance and simplicity, eventually reducing reliance on Zone.js entirely.
Dependency injection and services
Angular's DI system is hierarchical: a service marked @Injectable({ providedIn: 'root' }) is a singleton for the whole app by default, but a component or module can provide its own instance to scope it more narrowly. This is a structural difference from React, where sharing logic across components usually means a custom hook or context provider rather than a container resolving dependencies for you.
RxJS and the HttpClient
Angular's built-in HttpClient returns RxJS Observables, not Promises, and router events and reactive forms follow the same pattern. This is one of the framework's steeper learning-curve items: operators like map, switchMap, and takeUntil are genuinely necessary for non-trivial async code, and the async pipe in a template exists specifically to subscribe to and unsubscribe from an Observable automatically so a component doesn't have to manage that lifecycle by hand.
Mistakes people make here
- Confusing Angular with AngularJS
- AngularJS (1.x) and Angular (2 and later) are different frameworks that happen to share a name — the concepts, syntax, and even the language (JavaScript vs. TypeScript-first) don't carry over, so tutorials or job descriptions referencing one don't apply to the other.
- Manually subscribing to an Observable and never unsubscribing
- A subscription left open when a component is destroyed keeps doing work and holding references, which is a real memory leak — the async pipe, or an explicit takeUntil/unsubscribe pattern, exists specifically to avoid this.
- Mutating an object or array in place on a component using OnPush change detection
- OnPush checks inputs by reference, not by deep comparison — mutating an existing object won't trigger a re-render, so the fix is always creating a new reference (a new array or object) rather than editing the old one, the same underlying issue as React's setState rule.
- Treating RxJS as skippable because Promises feel simpler
- HttpClient, the router, and reactive forms all hand back Observables — avoiding RxJS operators just means reimplementing subscription management, cancellation, and combination logic by hand instead of using the tools built for exactly that.
Strengths and trade-offs
Where it is strong
- One official way to handle routing, forms, DI, and HTTP reduces "which library" decisions and keeps large, multi-team codebases more consistent than an assembled React stack tends to be.
- TypeScript-first design catches a real class of template and dependency-injection mistakes at compile time that a plain-JavaScript app would only surface at runtime.
- The Angular CLI scaffolds a full project with build tooling, testing, and linting already wired together, rather than assembled piece by piece.
- Maintained and used internally at Google on products like Google Cloud's console, which keeps it under active, well-resourced development rather than community-maintained alone.
The trade-offs
- A steeper learning curve than React: TypeScript, decorators, hierarchical DI, RxJS, and Angular's own template syntax are all up front, versus React's smaller conceptual core.
- Its opinionated structure is friction on a small app or a quick prototype, where React's willingness to skip a router or state library entirely is a genuine advantage.
- A smaller third-party ecosystem than React's outside Google's own official packages (Angular Material), so there are fewer competing options for many common needs.
- Ongoing internal migrations — NgModules to standalone components, Zone.js to signals — mean an older Angular codebase can look meaningfully different from a newly generated one, and modernizing a legacy app is real, non-trivial work.
Who needs this
Most relevant to teams building large, long-lived frontend applications with many contributors who benefit from one enforced structure, especially in enterprise or Google-adjacent environments; less essential for a small team or a project that wants the freedom to pick its own router and state-management combination the way React allows.
Questions about angular
- Is Angular the same as AngularJS?
- No. AngularJS (1.x) and Angular (2 and later) are different frameworks that share a name for historical reasons — Angular 2 was a complete rewrite, not an upgrade, and the two are not compatible with each other.
- Do I need to learn RxJS to use Angular?
- For anything beyond the basics, largely yes — HttpClient, the router, and reactive forms all use Observables. Signals reduce how much RxJS you need for local component state, but they haven't replaced it for HTTP calls or router events.
- Is Angular harder to learn than React?
- Generally, yes, up front — Angular introduces more concepts at once (TypeScript, decorators, DI, RxJS, its own template syntax) compared to React's smaller core of components and JavaScript. That investment tends to pay off more on larger, longer-lived codebases than on small ones.
- Is Angular a good fit for a small project?
- Often not the best fit — its structure and built-in tooling are overhead for a small app or prototype where React (or an even lighter tool) with a minimal setup usually gets you moving faster. Angular's advantages show up more clearly as a codebase and team grow.