O Angular é um framework TypeScript sob licença MIT mantido pelo Google, com reatividade baseada em sinais, renderização no servidor, uma CLI construída sobre Vite e esbuild e uma janela de suporte publicada de 24 meses por versão maior.
Já usou esta ferramenta? Avalie-a
Já usou esta ferramenta? Avalie-a
O Angular é um framework de aplicações web de código aberto mantido por uma equipe dedicada no Google, distribuído sob licença MIT e instalado a partir do npm em vez de comprado. O angular.dev é sua casa oficial de documentação.
O framework Angular é opinativo e não uma biblioteca. Roteamento, formulários, injeção de dependências, HTTP, internacionalização, testes e a cadeia de build chegam todos como peças de primeira parte versionadas em conjunto, e essa é a troca que o framework propõe: menos liberdade sobre qual biblioteca preenche cada lacuna, em troca de lacunas preenchidas de forma coerente e atualizadas no mesmo ritmo.
O desenvolvimento acontece à vista. Cada pull request e cada commit são públicos no GitHub, a equipe triaga issues por lá, e mudanças de maior porte passam por RFCs publicadas antes de aterrissar. A linha atual é a v22, lançada em junho de 2026.
Os sinais do Angular são a primitiva de reatividade, um modelo de granularidade fina combinado com otimizações em tempo de compilação em vez de uma varredura de detecção de mudanças por toda a árvore de componentes. É por esse eixo que o framework vem avançando há vários lançamentos, e a v22 concluiu a virada ao elevar Signal Forms, Angular Aria e as APIs de reatividade assíncrona ao estado pronto para produção.
Renderização no servidor e geração de site estático são ambas suportadas, com hidratação completa do DOM, de modo que uma aplicação pode ser entregue como marcação pré-renderizada e depois assumida no cliente sem descartar e reconstruir o DOM.
A Angular CLI é publicada no npm como o pacote @angular/cli e expõe um binário chamado ng, cobrindo de um só lugar o andaime, o desenvolvimento, os testes, a implantação e a manutenção. Por baixo, o pipeline de build se apoia em Vite e esbuild.
Ao longo da vida de um projeto, duas capacidades da CLI pesam mais que as demais:
O Angular DevTools fica ao lado das ferramentas de desenvolvedor do próprio navegador e acrescenta um inspetor de árvore de componentes, uma visão da árvore de injeção de dependências e um gráfico de chamas de perfilamento de desempenho personalizado. Do lado dos testes, o Vitest passou a ser o executor de testes principal após seu lançamento estável, e uma ferramenta de migração a partir do Karma caminha para a estabilidade.
A sanitização de HTML e o suporte a trusted types vêm embutidos, mirando o cross-site scripting e a falsificação de requisições. A internacionalização cobre tradução e formatação de mensagens, incluindo a sintaxe ICU do Unicode. Em ambos os casos o framework absorve uma preocupação que de outro modo seria uma decisão de biblioteca projeto a projeto.
A rampa de entrada documentada não começa por uma cadeia de ferramentas local: um ambiente interativo do StackBlitz significa que nenhuma configuração local é necessária até que você queira uma. Para avaliar se as convenções do framework servem a um time, isso tira a questão da versão do Node da primeira hora da decisão.
O suporte de versões do Angular é limitado no tempo e não indefinido, então atualizar é uma atividade planejada e não opcional. A sequência prática é rodar ng update sobre a CLI e os pacotes do núcleo juntos, deixar as transformações automatizadas de código que tratam mudanças de ruptura rotineiras cuidarem da parte mecânica e reservar tempo de revisão para as mudanças sem script de migração. Para a linha v22 o comando de migração é ng update @angular/cli@^22 @angular/core@^22.
Duas coisas determinam o quanto uma atualização vai doer. Primeiro, se o projeto está sequer sobre uma versão suportada: pular várias versões maiores fora de suporte obriga a encadear as migrações em vez de dar um salto único. Segundo, se você depende de APIs que entraram na janela de descontinuação, já que elas serão removidas numa fronteira maior.
Os caminhos documentados são três, escolhidos por onde a chamada ao modelo pertence e não por preferência: Genkit para a lógica no servidor, Firebase AI Logic para chamadas no cliente e a API Gemini diretamente. O Genkit exige um ambiente de servidor suportado, como um servidor baseado em Node, o que na prática significa uma aplicação Angular full-stack com SSR e não uma build apenas de cliente.
A regra de segurança presa aos três é inequívoca: nunca coloque uma chave de API num arquivo entregue ao cliente, como environments.ts. Aplicações somente de cliente devem rotear as chamadas ao modelo por Firebase AI Logic ou por um proxy que você controle; conexões no servidor devem ler credenciais de um gerenciador de segredos ou de variáveis de ambiente.
O Angular serve a times que preferem herdar decisões a tomá-las. O framework fornece um modelo de roteamento, um modelo de formulários, um contêiner de injeção e um pipeline de build, e espera que você os use. Para um time grande ou com rotatividade, essa coerência é justamente o ponto; para um projeto de duas pessoas, pode soar como cerimônia.
Serve bem quando:
Serve mal quando:
O Angular mira a plataforma web, e seu alcance é definido por duas matrizes publicadas em vez de uma alegação genérica de compatibilidade.
O suporte a navegadores é definido contra o conjunto «widely available» do Baseline em vez de uma lista de versões mantida à mão. Para cada versão maior, a equipe escolhe uma data Baseline próxima do lançamento e dá suporte a navegadores lançados dentro de 30 meses de uma data escolhida em Chrome, Edge, Firefox e Safari, mirando cerca de 95% dos usuários da web. A data Baseline da v22 é 2026-05-07.
A matriz da cadeia de ferramentas é mais rígida e vale conferir antes de uma atualização e não durante ela. A v22 prende o TypeScript à linha 6.0 e aceita Node 22.22.3, 24.15.0 ou 26.0.0, enquanto a v21 fica na linha TypeScript 5.9. Dentro de um projeto, a versão de @angular/core e a da CLI têm de coincidir, já que as duas compartilham número de versão maior desde a v7.
A documentação das linhas de pré-lançamento é servida à parte em next.angular.dev, de modo que avaliar um recurso não lançado não obriga a ler a documentação estável adivinhando o que mudou.
Não há tabela de preços, contagem de assentos nem faixa paga: o framework é publicado sob licença MIT e cada pacote é instalado a partir do registro público do npm. O aviso de copyright na licença do repositório diz 2010-2026 Google LLC, os metadados do npm de @angular/core carregam a mesma declaração MIT, e o lançamento publicado em vigor é o 22.1.5.
O que essa licença permite é amplo. A MIT autoriza uso comercial, modificação, distribuição e uso privado, com condições limitadas a manter os avisos de copyright e de licença; o software é fornecido sem garantia. Na prática não há custo por desenvolvedor, nem medição de uso, nem licença comercial a negociar antes de lançar um produto construído sobre ele.
O custo que resta não é de licenciamento e sim de manutenção. Como as versões maiores deixam o suporte segundo um calendário publicado, a linha real de orçamento é o tempo de engenharia da atualização anual, mais a capacidade de integração contínua que as suítes de build e teste consomem. Times que avaliam custo total deveriam precificar essa cadência em vez de supor que uma licença de custo zero implica uma dependência de custo zero.
Cada lançamento maior costuma ser suportado por 24 meses, divididos em doze meses de atualizações ativas e doze meses de suporte de longo prazo que carrega apenas correções críticas e de segurança. Isso é uma fronteira firme e não uma orientação: no momento em que isto é escrito, tudo da v2 à v19 está inteiramente fora de suporte, restando apenas a v22 em suporte ativo ao lado da v21 e da v20 em LTS.
A fase LTS é mais estreita do que «ainda suportado» sugere. Uma correção só é considerada se resolver uma vulnerabilidade de segurança recém-identificada, ou uma regressão desde o início do LTS causada por mudança de terceiros como uma nova versão de navegador. Bugs comuns descobertos durante o LTS ficam fora do escopo.
A descontinuação corre por relógio próprio. Uma API descontinuada sobrevive a pelo menos mais um lançamento maior, período de no mínimo doze meses, antes de virar candidata a remoção numa fronteira maior — e durante essa janela ela é mantida sob regras de LTS, recebendo portanto apenas correções críticas e de segurança mesmo enquanto o restante do lançamento está em suporte ativo.
A v22 ilustra o formato desse trabalho. A cobertura independente do lançamento nota que o suporte a Webpack, incluindo os pacotes mais antigos build-angular e ngtools, está descontinuado, que o lançamento exige TypeScript 6 e abandona o Node 20, e que dois itens precisam de atenção manual por não haver migração fornecida. A mudança de maior alcance é comportamental e não estrutural: OnPush passou a ser a estratégia padrão de detecção de mudanças dos componentes, e o padrão anterior foi renomeado Eager, com os schematics compensando ao anotar explicitamente os componentes existentes.
A compatibilidade retroativa é verificada mas não é absoluta. As mudanças passam por testes unitários e de integração, uma comparação das definições de tipos da API pública e as suítes de teste das aplicações dependentes do próprio Google — e ainda assim a política reserva que, em casos excepcionais como correções críticas de segurança, um conserto pode introduzir mudanças incompatíveis com o passado.
Duas fronteiras menores merecem ser ditas com franqueza. Polyfills têm um teto documentado: não conseguem transformar um navegador antigo e lento em um moderno e rápido, e o conjunto sugerido cobre apenas o necessário para rodar uma aplicação Angular completa, de modo que recursos fora desse conjunto podem exigir mais. A página oficial de política fixa a cadência completa: uma versão maior a cada doze meses, de quatro a seis versões menores por cada maior e uma versão corretiva ou pré-lançamento quase todas as semanas. Quanto ao intervalo maior em si, porém, as fontes publicadas divergem — uma descreve um ciclo de doze meses e a outra ainda descreve um de seis —, com a página oficial de política observando também que o ciclo mais longo começou na v22. Quem monta um orçamento plurianual de atualização deveria confirmar a cadência vigente na página de política e não em cobertura secundária.
Sim. O framework é publicado sob licença MIT e cada pacote é instalado a partir do registro público do npm, o que permite uso comercial, modificação e distribuição desde que os avisos de copyright e de licença sejam mantidos. O software é fornecido sem garantia.
Vinte e quatro meses no total para uma maior típica: doze meses de atualizações ativas e doze meses de suporte de longo prazo que carrega apenas correções críticas e de segurança. Depois disso a versão deixa o suporte por completo.
A v22 está em suporte ativo, com a v21 e a v20 em LTS. Tudo da v2 à v19 está inteiramente fora de suporte.
A v22 prende o TypeScript à linha 6.0 e aceita Node 22.22.3, 24.15.0 ou 26.0.0. A matriz de versões é publicada por lançamento e vale conferir antes de iniciar uma atualização, não no meio dela.
A CLI carrega boa parte: ng update executa transformações automatizadas de código que tratam mudanças de ruptura rotineiras. O que ela não cobre são mudanças de comportamento sem script de migração — na v22 isso incluiu um padrão de roteamento sem migração fornecida, ao lado da descontinuação do suporte a Webpack.
O suporte segue a definição «widely available» do Baseline: navegadores lançados dentro de 30 meses de uma data escolhida em Chrome, Edge, Firefox e Safari, mirando cerca de 95% dos usuários da web. Cada versão maior escolhe sua própria data Baseline próxima do lançamento.
Sim, para avaliação. Um ambiente interativo do StackBlitz significa que nenhuma configuração local é necessária até que você queira uma, e esse é o ponto de partida documentado dos tutoriais no navegador.
Escolha o caminho por onde a chamada pertence — Genkit para a lógica no servidor, Firebase AI Logic para chamadas no cliente e a API Gemini diretamente — e observe a regra de credenciais: nunca coloque uma chave de API num arquivo entregue ao cliente, como environments.ts.
