Casi todas las listas de frameworks PHP que circulan tienen el mismo problema: mezclan proyectos con versiones de este año y proyectos que no publican una versión desde hace cinco. Elegir mal por ahí sale caro, porque un framework sin mantenimiento deja de recibir parches de seguridad y arrastra a la aplicación entera. Esta comparativa va con versiones, fechas y estado de soporte comprobados, y con una sección aparte para los que ya no deberían aparecer en ninguna recomendación.
El punto de partida no ha cambiado: PHP sigue siendo el lenguaje de servidor dominante. Según W3Techs, lo usa el 69,9 % de los sitios cuyo lenguaje de servidor se conoce, una precisión que conviene mantener porque no es lo mismo que decir el 69,9 % de toda la web.
Estado real a día de hoy
| Framework | Última versión | PHP mínimo | Para qué encaja |
|---|---|---|---|
| Laravel | 13 (marzo de 2026) | 8.3 | Aplicaciones completas con equipo detrás |
| Symfony | 8.1 estable · 7.4 LTS | 8.4 · 8.2 en la LTS | Proyectos largos y APIs |
| CodeIgniter 4 | 4.7.4 (julio de 2026) | 8.2 | Proyectos medianos sin ceremonia |
| CakePHP | 5.4.2 (septiembre de 2026) | 8.2 | Convención sobre configuración |
| Slim | 4.15.3 (septiembre de 2026) | 7.4 | APIs pequeñas y microservicios |
| Yii 2 | 2.0.55 (mayo de 2026) | 7.4 | Mantenimiento de lo ya existente |
Laravel y Symfony: los dos que sostienen el ecosistema
Laravel ha seguido su cadencia anual y va por la versión 13, publicada en marzo de 2026, que pide PHP 8.3 como mínimo. Lo que más condiciona la planificación no es la versión sino su política de soporte: cada rama recibe correcciones de fallos durante 18 meses y parches de seguridad durante dos años. Traducido, quien esté en Laravel 11 lleva desde marzo de 2026 sin cobertura, y quien esté en la 12 la pierde en febrero de 2027.
Sigue siendo la opción más cómoda para una aplicación completa: Eloquent, Blade, migraciones, colas y una CLI que cubre casi todo el trabajo repetitivo. El precio es el ritmo de actualización, que obliga a subir de rama con regularidad.
Symfony juega al contrario y por eso convive con Laravel en vez de competir de frente. Publica una versión menor cada seis meses, en mayo y noviembre, una mayor cada dos años, y designa una LTS con tres años de soporte. Ahora mismo la estable es la 8.1, que exige PHP 8.4, y la LTS es la 7.4, con correcciones hasta noviembre de 2028 y parches de seguridad hasta noviembre de 2029.
Esa LTS es el argumento de peso para proyectos que se entregan a un cliente y tienen que sobrevivir varios años sin refactorizaciones grandes. Conviene recordar también que Symfony no es solo un framework: buena parte de sus componentes están dentro de Laravel, de Drupal y de medio ecosistema PHP.
Los ligeros, cuando el proyecto no da para tanto
CodeIgniter 4 mantiene un ritmo tranquilo pero constante, con la 4.7.4 publicada en julio de 2026 y PHP 8.2 como mínimo. Sigue siendo la respuesta razonable para algo mediano que hay que entregar pronto, sin la ceremonia de un framework completo ni la curva de Symfony.
Slim es el microframework con mejor salud de la lista: la 4.15.3 es de septiembre de 2026 y declara compatibilidad hasta PHP 8.5. Para una API con unos cuantos endpoints o un servicio interno, evita cargar con un framework de propiedades que no se van a usar.
CakePHP sigue publicando con regularidad, con la 5.4.2 de septiembre de 2026. Su apuesta por la convención sobre la configuración encaja bien en equipos pequeños que prefieren decidir poco y escribir más lógica.
Los que hay que mirar con lupa
Yii 2 sigue recibiendo versiones, la 2.0.55 es de mayo de 2026, y arrastra una base instalada enorme. Pero la rama 3 lleva años en desarrollo sin fecha clara, así que empezar un proyecto nuevo aquí significa asumir esa incertidumbre. Para mantener lo que ya existe, ningún problema.
Phalcon mantiene su planteamiento particular, escrito en C e instalado como extensión de PHP, lo que le da un consumo de memoria muy bajo. La contrapartida es operativa: hay que compilar o instalar la extensión en cada servidor, algo que no todos los alojamientos permiten y que complica los despliegues.
Swoole y OpenSwoole tampoco son frameworks sino entornos de ejecución asíncrona, con corrutinas y servidores persistentes. Tienen sentido cuando hay miles de conexiones simultáneas de por medio, y conviven con los frameworks anteriores en lugar de sustituirlos.
Los que ya no deberían estar en ninguna lista
Aquí está el motivo de revisar estas comparativas cada cierto tiempo:
- Laminas MVC, el heredero de Zend Framework, está retirado. El equipo anunció en junio de 2025 que pasaba a modo solo seguridad y que el abandono definitivo llegaría con la salida de PHP 8.5, sin más versiones después. La recomendación oficial del propio proyecto es migrar a Mezzio, su microframework de middleware PSR-15.
- FuelPHP publicó su última versión, la 1.9.0, en diciembre de 2021. Cinco años sin releases no es un parón, es un final.
Los dos seguían apareciendo en la versión anterior de este artículo, y siguen apareciendo en la mayoría de listas que se encuentran buscando. Un framework sin mantenimiento no es solo una decisión técnica conservadora: es una aplicación que dejará de recibir parches cuando aparezca la siguiente vulnerabilidad.
Cómo decidir sin arrepentirse en dos años
- Mira primero la fecha de la última versión, no las estrellas de GitHub ni el número de tutoriales. Un proyecto sin releases en el último año ya está diciendo algo.
- Comprueba hasta cuándo hay parches para la rama concreta que vas a usar, no para el framework en general.
- Cruza el PHP mínimo con tu alojamiento. Symfony 8.1 pide PHP 8.4, y ahí se caen bastantes servidores compartidos todavía en 8.1 u 8.2.
- Pesa el coste de actualizar. Una cadencia anual con 18 meses de correcciones obliga a reservar tiempo de mantenimiento cada año; una LTS de tres años lo concentra en una sola migración mayor.
El rendimiento final depende también de dónde corre el proyecto, algo que repasamos con datos en las cifras del Web Almanac sobre CMS y rendimiento. Y si el proyecto es WordPress, que también va sobre PHP, está nuestra guía de estrategias de rendimiento en WordPress.
Preguntas frecuentes
¿Cuál es el framework PHP más usado?
Laravel, por ecosistema y por comunidad, con Symfony detrás y presente además dentro del propio Laravel a través de sus componentes. Para elegir entre los dos pesa más la política de soporte que la popularidad.
¿Qué versión de PHP necesito?
Depende del framework: Laravel 13 pide PHP 8.3, Symfony 8.1 pide 8.4, CodeIgniter 4 y CakePHP 5 se conforman con 8.2 y Slim 4 llega hasta compatibilidad con 7.4. Conviene comprobarlo antes de elegir alojamiento.
¿Sigue vivo Zend Framework o Laminas?
Laminas MVC, su heredero, está retirado: pasó a modo solo seguridad en 2025 y el abandono definitivo llegó con PHP 8.5. El propio proyecto recomienda migrar a Mezzio.
¿Qué framework elijo para una API pequeña?
Slim, que sigue publicando versiones y pesa lo justo, o Mezzio si el equipo ya trabaja con middleware PSR-15. Montar Laravel completo para cuatro endpoints suele salir caro en mantenimiento.
¿Empiezo un proyecto nuevo con Yii?
Para mantener aplicaciones existentes sí, porque Yii 2 sigue recibiendo versiones. Para algo nuevo, la rama 3 lleva años en desarrollo sin fecha, y esa incertidumbre pesa.
Fuentes
- Symfony releases, calendario de versiones y mantenimiento
- endoflife.date, ciclo de soporte de Laravel
- Laminas Project, Laminas MVC is retiring
- Packagist, versiones publicadas de CodeIgniter, CakePHP, Slim, Yii y FuelPHP
- W3Techs, cuota de uso de PHP
