Angular is an MIT-licensed TypeScript framework maintained by Google, with signal-based reactivity, server-side rendering, a Vite and esbuild CLI, and a published 24-month support window per major release.
Used this tool? Rate it
Used this tool? Rate it
Angular is an open-source web application framework maintained by a dedicated team at Google, distributed under the MIT licence and installed from npm rather than bought. angular.dev is its official documentation home.
The Angular framework is opinionated rather than a library. Routing, forms, dependency injection, HTTP, internationalisation, testing and the build toolchain all ship as first-party pieces that are versioned together, which is the trade the framework asks you to make: less choice about which library fills each slot, in exchange for those slots being filled consistently and upgraded in step.
Development happens in the open: every pull request and commit is available on our GitHub, in the project's own words, the team triages issues there, and larger changes go through published RFCs before they land. The current line is v22, released in June 2026.
Signals are the reactivity primitive, a fine-grained model combined with compile-time optimizations rather than a change-detection sweep over the whole component tree. Angular signals replaced the older zone-driven approach as the default way to describe state. This is the axis along which the framework has been moving for several releases, and v22 completed the shift by promoting Signal Forms, Angular Aria and the asynchronous reactivity APIs to production-ready status.
Server-side rendering and static site generation are both supported, with full DOM hydration, and so an application can be delivered as pre-rendered markup and then take over on the client without discarding and rebuilding the DOM.
The Angular CLI is published on npm as the @angular/cli package and exposing a binary named ng, and it covers scaffolding, development, testing, deployment and maintenance from one place. Underneath, the build pipeline is built on Vite and esbuild.
Two CLI capabilities matter more than the rest over a project's lifetime:
Angular DevTools sits alongside the browser's own developer tools and adds a component tree inspector, a dependency injection tree view and a custom performance profiling flame chart. On the testing side, Vitest became the primary test runner following its stable release, and a migration tool from Karma is being taken to stable.
HTML sanitization and trusted type support are built in, aimed at cross-site scripting and cross-site request forgery. Internationalisation covers message translation and formatting, including Unicode ICU syntax. Both are cases where the framework absorbs a concern that would otherwise be a per-project library decision.
The documented on-ramp does not begin with a local toolchain: an interactive StackBlitz environment means no local setup is needed until you want one. For evaluating whether the framework's conventions suit a team, that removes the Node-version question from the first hour of the decision.
Angular version support is time-boxed rather than open-ended, so upgrades are a scheduled activity rather than an optional one. The practical sequence is to run ng update against the CLI and core packages together, let the tooling do the mechanical rewriting, and then reserve review time for the changes that carry no migration script. For the v22 line the migration command is ng update @angular/cli@^22 @angular/core@^22.
Two things determine how painful a given upgrade will be. First, whether your project sits on a supported version at all — jumping across several unsupported majors means running the migrations in sequence rather than in one hop. Second, whether you depend on APIs that have entered their deprecation window, since those will be removed at a major boundary.
The documented paths are three, chosen by where the model call belongs rather than by preference: Genkit for server-side logic, Firebase AI Logic for client-side calls, and the Gemini API directly. Genkit requires a supported server environment such as a Node-based server, which in practice means a full-stack Angular application with SSR rather than a client-only build.
The security rule attached to all three is unambiguous: never place an API key in a file that ships to the client, such as environments.ts. Client-only applications should route model calls through Firebase AI Logic or a proxy you control; server-side connections should read credentials from a secrets manager or environment variables.
Angular fits teams that would rather inherit decisions than make them. The framework supplies a routing model, a forms model, a DI container and a build pipeline, and expects you to use them. For a large or rotating team that consistency is the point; for a two-person project it can read as ceremony. The framework's own regression net is unusually large: every commit is checked against hundreds of thousands of tests in Google's internal code repository before it lands.
It fits well when:
It fits poorly when:
Angular targets the web platform, and its reach is defined by two published matrices rather than by a general claim of compatibility.
Browser support is defined against the Baseline "widely available" set rather than a hand-maintained list of versions. For each major, the team picks a Baseline date near release and supports browsers released within 30 months of a chosen date across Chrome, Edge, Firefox and Safari, targeting roughly 95% of web users. The v22 Baseline date is 2026-05-07.
The toolchain matrix is stricter and worth checking before an upgrade rather than during one. v22 pins TypeScript to the 6.0 line and accepts Node 22.22.3, 24.15.0 or 26.0.0, while v21 sits on the TypeScript 5.9 line. Within a project, the version of @angular/core and the CLI have to match, since the two have shared a major version number since v7.
Documentation for pre-release lines is served separately at next.angular.dev, so evaluating an unreleased feature does not mean reading stable docs and guessing what changed.
There is no price list, no seat count and no paid tier: the framework is released under the MIT licence and every package is installed from the public npm registry. The copyright notice on the repository licence reads 2010-2026 Google LLC, and the npm metadata for @angular/core carries the same MIT declaration, with 22.1.5 as the current published release.
Because the framework runs entirely on infrastructure you control, the rights question is a licensing question rather than a data-processing one. What that licence permits is broad. MIT allows commercial use, modification, distribution and private use, with the conditions limited to retaining the copyright and licence notice; the software is provided without warranty. In practical terms there is no per-developer cost, no usage metering and no commercial licence to negotiate before shipping a product built on it.
The cost that remains is not licensing but maintenance. Because major versions leave support on a published schedule, the real budget line is engineering time for the annual upgrade, plus whatever CI capacity the build and test suites consume. Teams evaluating total cost should price that cadence rather than assume that a zero-cost licence implies a zero-cost dependency.
Each major release is typically supported for 24 months, split into twelve months of active updates and twelve months of long-term support that carries only critical and security fixes. That is a firm boundary, not a guideline: at the time of writing, everything from v2 through v19 is out of support entirely, leaving only v22 in active support alongside v21 and v20 in LTS.
The LTS phase is narrower than "still supported" suggests. A fix is considered only if it resolves a newly identified security vulnerability, or a regression since the start of LTS caused by a third-party change such as a new browser version. Ordinary bugs discovered during LTS are not in scope.
Deprecation runs on its own clock: a deprecated API survives at least one further major release, a period of at least twelve months, after which it becomes a candidate for removal at a major boundary — and during that window it is maintained under LTS rules, so it receives only critical and security fixes even while the rest of the release is under active support.
v22 illustrates the shape of the work. Independent reporting on the release notes that Webpack support, including the older build-angular and ngtools packages, is deprecated, that the release requires TypeScript 6 and drops Node 20, and that two items need manual attention because no migration is provided. The most far-reaching change is behavioural rather than structural: OnPush became the default change detection strategy for components, and the previous default was renamed Eager, which schematics handle by annotating existing components explicitly.
Backwards compatibility is verified but not absolute. Changes are checked against unit and integration tests, a diff of the public API type definitions, and the test suites of Google's own dependent applications — yet the policy still reserves that in exceptional cases, such as critical security patches, a fix may introduce backwards incompatible changes.
Two smaller boundaries are worth stating plainly. Polyfills have a documented ceiling: they cannot turn an old, slow browser into a modern fast one, and the suggested set covers only what is needed to run a full Angular application, so features outside that set may need more. The official policy page sets the full cadence as a major release every twelve months, four to six minor releases for each major, and a patch or pre-release build almost every week. Published sources currently disagree on the major interval itself — one describing a twelve-month cycle and the other still describing a six-month one — with the official policy page also noting that the longer cycle began with v22. Anyone planning a multi-year upgrade budget should confirm the current cadence against the policy page rather than against secondary coverage.
Yes. The MIT terms permit commercial use, modification and distribution provided the copyright and licence notice are retained, and the software is supplied without warranty.
Twenty-four months in total for a typical major, split evenly between an active phase and an LTS phase. After that the version leaves support entirely.
v22 is in active support, with v21 and v20 in LTS. Everything from v2 through v19 is out of support entirely.
The current line requires the TypeScript 6.0 range and one of three Node lines. The version matrix is published per release and is worth checking before starting an upgrade rather than during it.
The CLI carries much of it, since ng update rewrites the mechanical parts for you. What it cannot cover is behavioural change without a migration script — in v22 that included a routing default with no migration provided, alongside the retirement of the older bundler path.
Support follows the Baseline "widely available" definition, which admits the recent releases of the four core browser engines and aims at roughly nineteen users in twenty. Each major picks its own Baseline date near release.
Yes, for evaluation. The documented starting point for the in-browser tutorials runs entirely in a hosted editor, so a local toolchain can wait until you commit to the framework.
Pick the path by where the call belongs, then observe the credential rule that applies to all three: secrets stay on the server or behind a managed proxy, never in a bundle the browser downloads.
