Angular es un framework de TypeScript con licencia MIT mantenido por Google, con reactividad basada en señales, renderizado en servidor, una CLI construida sobre Vite y esbuild, y una ventana de soporte publicada de 24 meses por versión mayor.
¿Has usado esta herramienta? Valórala
¿Has usado esta herramienta? Valórala
Angular es un framework de aplicaciones web de código abierto mantenido por un equipo dedicado en Google, distribuido bajo licencia MIT e instalado desde npm en lugar de comprado. angular.dev es su sede documental oficial.
El framework Angular tiene criterio propio y no es una biblioteca. Enrutado, formularios, inyección de dependencias, HTTP, internacionalización, pruebas y la cadena de construcción llegan todos como piezas de primera parte versionadas en conjunto, y ese es el trato que el framework propone: menos margen para elegir qué biblioteca ocupa cada hueco, a cambio de que esos huecos se llenen de forma coherente y se actualicen al mismo paso.
El desarrollo ocurre a la vista. Cada pull request y cada commit son públicos en GitHub, el equipo clasifica allí las incidencias, y los cambios de mayor calado pasan por RFC publicadas antes de aterrizar. La línea actual es la v22, publicada en junio de 2026.
Las señales de Angular son la primitiva de reactividad, un modelo de grano fino combinado con optimizaciones en tiempo de compilación en lugar de un barrido de detección de cambios sobre todo el árbol de componentes. Ese es el eje por el que el framework lleva varias versiones avanzando, y la v22 completó el giro al elevar Signal Forms, Angular Aria y las API de reactividad asíncrona a estado listo para producción.
El renderizado en servidor y la generación de sitios estáticos están ambos soportados, con hidratación completa del DOM, de modo que una aplicación puede entregarse como marcado prerenderizado y luego tomarse desde el cliente sin descartar ni reconstruir el DOM.
Angular CLI se publica en npm como el paquete @angular/cli y expone un binario llamado ng, cubriendo desde un mismo lugar el andamiaje, el desarrollo, las pruebas, el despliegue y el mantenimiento. Por debajo, la tubería de construcción se apoya en Vite y esbuild.
A lo largo de la vida de un proyecto, dos capacidades de la CLI pesan más que el resto:
Angular DevTools se coloca junto a las herramientas de desarrollo del propio navegador y añade un inspector del árbol de componentes, una vista del árbol de inyección de dependencias y un gráfico de llamas de perfilado de rendimiento personalizado. En el lado de pruebas, Vitest pasó a ser el ejecutor de pruebas principal tras su publicación estable, y una herramienta de migración desde Karma avanza hacia la estabilidad.
La sanitización de HTML y el soporte de trusted types vienen integrados, apuntando al scripting entre sitios y a la falsificación de peticiones. La internacionalización cubre la traducción y el formateo de mensajes, incluida la sintaxis ICU de Unicode. En ambos casos el framework absorbe una preocupación que de otro modo sería una decisión de biblioteca proyecto a proyecto.
La rampa de acceso documentada no arranca con una cadena de herramientas local: un entorno interactivo de StackBlitz significa que no hace falta configuración local hasta que la quieras. Para juzgar si las convenciones del framework encajan con un equipo, eso retira la cuestión de la versión de Node de la primera hora de la decisión.
El soporte de versiones de Angular está acotado en el tiempo en lugar de ser indefinido, así que actualizar es una actividad programada y no opcional. La secuencia práctica consiste en ejecutar ng update sobre la CLI y los paquetes del núcleo a la vez, dejar que las transformaciones de código automatizadas que atienden los cambios de ruptura rutinarios hagan el trabajo mecánico, y reservar tiempo de revisión para los cambios sin guion de migración. Para la línea v22 el comando de migración es ng update @angular/cli@^22 @angular/core@^22.
Dos cosas determinan cuánto duele una actualización concreta. Primero, si el proyecto se apoya siquiera en una versión soportada: saltar varias versiones mayores fuera de soporte obliga a encadenar las migraciones en lugar de dar un único brinco. Segundo, si dependes de API que han entrado en su ventana de obsolescencia, ya que se retirarán en una frontera mayor.
Los caminos documentados son tres, y se eligen según dónde corresponda la llamada al modelo y no por preferencia: Genkit para la lógica en servidor, Firebase AI Logic para llamadas desde el cliente, y la API de Gemini directamente. Genkit exige un entorno de servidor soportado, como un servidor basado en Node, lo que en la práctica implica una aplicación Angular full-stack con SSR y no una compilación solo de cliente.
La regla de seguridad que acompaña a los tres es inequívoca: nunca coloques una clave de API en un archivo que se entregue al cliente, como environments.ts. Las aplicaciones solo de cliente deben enrutar las llamadas al modelo a través de Firebase AI Logic o de un proxy que controles; las conexiones de servidor deben leer las credenciales de un gestor de secretos o de variables de entorno.
Angular encaja con equipos que prefieren heredar decisiones antes que tomarlas. El framework aporta un modelo de enrutado, un modelo de formularios, un contenedor de inyección y una tubería de construcción, y espera que los uses. Para un equipo grande o con rotación esa coherencia es justamente el punto; para un proyecto de dos personas puede leerse como ceremonia.
Encaja bien cuando:
Encaja mal cuando:
Angular apunta a la plataforma web, y su alcance se define mediante dos matrices publicadas y no mediante una afirmación general de compatibilidad.
El soporte de navegadores se define frente al conjunto «widely available» de Baseline y no frente a una lista de versiones mantenida a mano. Para cada versión mayor, el equipo elige una fecha Baseline cercana a la publicación y da soporte a los navegadores aparecidos dentro de los 30 meses previos a una fecha elegida en Chrome, Edge, Firefox y Safari, apuntando a alrededor del 95 % de los usuarios de la web. La fecha Baseline de la v22 es el 2026-05-07.
La matriz de la cadena de herramientas es más estricta y conviene revisarla antes de una actualización y no durante ella. La v22 fija TypeScript en la línea 6.0 y acepta Node 22.22.3, 24.15.0 o 26.0.0, mientras que la v21 se sitúa en la línea TypeScript 5.9. Dentro de un proyecto, la versión de @angular/core y la de la CLI deben coincidir, ya que ambas comparten número de versión mayor desde la v7.
La documentación de las líneas de preversión se sirve aparte en next.angular.dev, así que evaluar una función no publicada no obliga a leer la documentación estable adivinando qué cambió.
No hay lista de precios, ni recuento de asientos, ni nivel de pago: el framework se publica bajo licencia MIT y cada paquete se instala desde el registro público de npm. El aviso de copyright en la licencia del repositorio dice 2010-2026 Google LLC, los metadatos de npm de @angular/core llevan la misma declaración MIT, y la publicación vigente es la 22.1.5.
Lo que esa licencia permite es amplio. MIT autoriza el uso comercial, la modificación, la distribución y el uso privado, con condiciones limitadas a conservar los avisos de copyright y de licencia; el software se entrega sin garantía. En términos prácticos no hay coste por desarrollador, ni medición de uso, ni licencia comercial que negociar antes de lanzar un producto construido sobre él.
El coste que queda no es de licencia sino de mantenimiento. Puesto que las versiones mayores abandonan el soporte según un calendario publicado, la partida presupuestaria real es el tiempo de ingeniería de la actualización anual, más la capacidad de integración continua que consumen las suites de construcción y pruebas. Los equipos que evalúen el coste total deberían poner precio a esa cadencia en vez de suponer que una licencia sin coste implica una dependencia sin coste.
Cada versión mayor se soporta habitualmente 24 meses, repartidos en doce meses de actualizaciones activas y doce meses de soporte a largo plazo que solo lleva correcciones críticas y de seguridad. Es una frontera firme y no una orientación: al momento de escribir, todo lo que va de la v2 a la v19 está por completo fuera de soporte, dejando solo la v22 en soporte activo junto a la v21 y la v20 en LTS.
La fase LTS es más estrecha de lo que sugiere «todavía soportado». Una corrección se considera únicamente si resuelve una vulnerabilidad de seguridad recién identificada, o una regresión desde el inicio del LTS causada por un cambio de terceros como una nueva versión de navegador. Los fallos ordinarios descubiertos durante el LTS quedan fuera del alcance.
La obsolescencia corre según su propio reloj. Una API obsoleta sobrevive al menos a una versión mayor más, un periodo de al menos doce meses, tras lo cual pasa a ser candidata a retirada en una frontera mayor; y durante esa ventana se mantiene bajo reglas LTS, de modo que solo recibe correcciones críticas y de seguridad aun cuando el resto de la publicación esté en soporte activo.
La v22 ilustra la forma de ese trabajo. La cobertura independiente de la publicación señala que el soporte de Webpack, incluidos los paquetes más antiguos build-angular y ngtools, queda obsoleto, que la publicación exige TypeScript 6 y abandona Node 20, y que dos puntos requieren atención manual al no proporcionarse migración. El cambio de mayor alcance es de comportamiento y no estructural: OnPush pasó a ser la estrategia de detección de cambios por defecto de los componentes, y el valor por defecto anterior se renombró Eager, con los schematics compensando mediante la anotación explícita de los componentes existentes.
La compatibilidad hacia atrás se verifica pero no es absoluta. Los cambios se contrastan con pruebas unitarias y de integración, una comparación de las definiciones de tipos de la API pública y las suites de pruebas de las aplicaciones dependientes de la propia Google; y aun así la política reserva que, en casos excepcionales como parches críticos de seguridad, una corrección pueda introducir cambios incompatibles hacia atrás.
Dos fronteras menores merecen enunciarse con franqueza. Los polyfills tienen un techo documentado: no pueden convertir un navegador viejo y lento en uno moderno y rápido, y el conjunto sugerido solo cubre lo necesario para ejecutar una aplicación Angular completa, de modo que funciones fuera de ese conjunto pueden exigir más. La página oficial de política fija la cadencia completa: una versión mayor cada doce meses, de cuatro a seis versiones menores por cada mayor y una versión correctiva o preliminar casi cada semana. Sobre el intervalo mayor en sí, en cambio, las fuentes publicadas divergen —una describe un ciclo de doce meses y la otra sigue describiendo uno de seis—, y la página oficial de política añade que el ciclo más largo comenzó con la v22. Quien elabore un presupuesto de actualización a varios años debería confirmar la cadencia vigente en la página de política y no en cobertura secundaria.
Sí. El framework se publica bajo licencia MIT y cada paquete se instala desde el registro público de npm, lo que permite uso comercial, modificación y distribución siempre que se conserven los avisos de copyright y de licencia. El software se entrega sin garantía.
Veinticuatro meses en total para una mayor típica: doce meses de actualizaciones activas y doce meses de soporte a largo plazo que solo lleva correcciones críticas y de seguridad. Después la versión abandona el soporte por completo.
La v22 está en soporte activo, con la v21 y la v20 en LTS. Todo lo que va de la v2 a la v19 está por completo fuera de soporte.
La v22 fija TypeScript en la línea 6.0 y acepta Node 22.22.3, 24.15.0 o 26.0.0. La matriz de versiones se publica por cada versión y conviene consultarla antes de iniciar una actualización, no a mitad de camino.
La CLI carga con buena parte: ng update ejecuta transformaciones de código automatizadas que atienden los cambios de ruptura rutinarios. Lo que no puede cubrir son los cambios de comportamiento sin guion de migración; en la v22 eso incluyó un valor por defecto de enrutado sin migración proporcionada, junto a la obsolescencia del soporte de Webpack.
El soporte sigue la definición «widely available» de Baseline: navegadores aparecidos dentro de los 30 meses previos a una fecha elegida en Chrome, Edge, Firefox y Safari, apuntando a alrededor del 95 % de los usuarios de la web. Cada versión mayor escoge su propia fecha Baseline cercana a la publicación.
Sí, para evaluar. Un entorno interactivo de StackBlitz significa que no hace falta configuración local hasta que la quieras, y ese es el punto de partida documentado de los tutoriales dentro del navegador.
Elige el camino según dónde corresponda la llamada —Genkit para la lógica en servidor, Firebase AI Logic para llamadas desde el cliente, y la API de Gemini directamente— y respeta la regla de credenciales: nunca coloques una clave de API en un archivo que se entregue al cliente, como environments.ts.
