PHP es Legacy, en 2024

En Vonage viajamos mucho en nuestro trabajo. Hablo con muchos desarrolladores de todo tipo, y puedo decir con confianza que una de las preguntas que más me hacen es: ¿Por qué sigues haciendo PHP? Variaciones de esta pregunta pueden ser "¿No se supone que PHP es malo?" En varias ocasiones, la persona con la que estaba hablando había hecho algo de PHP en 2012. O 2010. No recuerdo. Por razones que no entiendo, estamos pasando por otra racha de esto dentro de los foros en línea mucho, y así más "PHP es terrible" comentarios están saliendo de la carpintería.

¿Cuál es la causa de este fenómeno? ¿Por qué PHP es "malo"?

Tribus

Considero que la mayoría de los desarrolladores son personas que empiezan como nómadas y acaban "encontrando su tribu"... Al fin y al cabo, eso es lo que son las comunidades tecnológicas. Una de las dificultades al empezar (aparte de conseguir tu primer trabajo) es ser aceptado o elegir a qué tribu quieres llamar hogar. A algunos les resulta difícil ser aceptados, y aquí es donde se puede utilizar el humor o un terreno común para los graduados o los "boot campers".

A este respecto, el chiste más conocido es "PHP es malo", pero ya no hay razonamiento que lo respalde; lo más parecido que alguien puede dar como explicación es una enorme y farragosa entrada de blog escrita hace años sobre muchas, muchas cosas que nunca encontrarás o que sólo son una molestia para su autor. No importa que han salido contra-posts como este de Slack Engineering que explican el matiz de que cualquier aplicación se puede escribir mal en cualquier lenguaje de programación. Supongo que algunos se apresurarán a señalar que Slack construyó originalmente su plataforma con Hackuna bifurcación de PHP creada por Facebook, o que muchos de los nuevos servicios que han añadido desde entonces están en Go o Node.

Así pues, el escenario sigue siendo el mismo: es malo.

El mito que se perpetúa a sí mismo

PHP es tan malo, de hecho, que un cierto sistema operativo decidió emitir una advertencia cuando se intenta utilizar la versión que viene con él, indicando:

ADVERTENCIA: No se recomienda el uso de PHP

Sin tener en cuenta el hecho de que la versión que se entregaba con él ya estaba desactualizada, la gente defendió la redacción explicando que la intención era advertir a la gente sobre la versión heredada de PHP con la que venía el sistema operativo.

Se descubrió que hacía lo mismo con Python 2.7, pero lo más importante es que el mensaje de error decía explícitamente "No se recomienda Python 2.7", sin la etiqueta de advertencia. Eso no es lo que dice este mensaje de error.

Algunas personas pueden encontrarlo gracioso, pero yo no encuentro ningún humor en que mi Sistema Operativo me diga qué lenguaje de programación debo usar. Esta es la auto-perpetuación de que PHP es malo, y por qué este guiño está bien.

Entonces, ¿por qué seguimos hablando de PHP si se supone que es malo?

La necesidad es la madre de la invención

Hay otro lenguaje de programación que ha seguido exactamente el mismo patrón de evolución: JavaScript. Como JavaScript era el de-facto que se ejecutaba dentro de un navegador con un motor incorporado. tenía que evolucionar desde sus comienzos básicos.

Del mismo modo, debido al auge de los sistemas de gestión de contenidos, que son backends escritos en PHP, como WordPress y Drupal: PHP tuvo que evolucionar. La evolución de un lenguaje de Rasmus Lerdorf de C para su propio uso de secuencias de comandos en un lenguaje de programación general de pleno derecho diseñado para la web no sucede por accidente. Un paso adelante Zend, que creó el motor Zend y, de manera crucial, consiguió la colaboración de los principales proveedores del momento, como Oracle e IBM.

Estas cosas pasan porque la gente las usade la misma manera que la relación entre JavaScript y ECMAScript y el ecosistema de herramientas evolucionan constantemente.

Esta evolución se ha producido precisamente porque PHP sigue siendo ampliamente usado - sin su uso generalizado nunca habríamos visto cosas como el cambio a un sistema de clases completamente orientado a objetos en 5.0, traits en 5.4, la introducción de generadores en 5.6, un motor rediseñado en PHP7 que vio un aumento de rendimiento del 100% en algunos casos, un compilador JIT para 8.0 y enums nativos en 8.1. El ciclo de vida de Perl, por ejemplo, no lo vio evolucionar rápidamente porque la gente dejó de usarlo. Entonces, ¿cuáles son los resultados reales de esta evolución que estamos viendo hoy?

Mito nº 1: PHP no es escalable.

Trate de decirle eso a Fathom Analytics, que reescribió su aplicación en Laravel y lidian con millones de peticiones por segundo.

Aclaremos esto cualquier microservicio o sistema distribuido no escalará eficazmente si lo diseñas mal..

El caso de Fathom muestra que se puede hacer esto - en su caso, dentro del espacio Laravel - de manera muy eficaz con un arsenal de herramientas que vienen de Laravel. Como Jack menciona en la entrada del blog anterior, la crítica de los programadores que utilizan otros lenguajes es que PHP no puede escalar porque los puntos de referencia lo dicen.

Pero cuando se crea una aplicación a gran escala, ¿se necesita que gestione un millón de peticiones por minuto? Probablemente no. Pero sin duda sería agradable y rápido en Node porque es asíncrono, ¿verdad? Seguramente. ¿Te importa? Poco probable en esta etapa.

Mito nº 2: PHP es lento

Una crítica común es que debido a que PHP es de un solo hilo, hay que generar nuevos procesos para crear trabajo concurrente o cargas de trabajo de escala horizontal. El PHP-JIT fue introducido en PHP8.0pero ese fue solo el comienzo de los cambios que hicieron de la velocidad la agenda principal para la evolución de PHP. Fui introducido a OpenSwoole (luego Swoole) en 2014y vi una solución de extensión para el problema de un solo hilo. El advenimiento de Fibras nativas en PHP8.1 significó entonces que se podría lograr PHP coroutines/asynchronous. A buen ejemplo de benchmarking puede encontrarse aquípero el resumen de esta evolución a la velocidad significa que ahora hay varias opciones para que los desarrolladores PHP escriban aplicaciones a la velocidad del rayo.

Coroutines de fibra

ReactPHP y amphp son dos ejemplos del uso de fibras para PHP asíncrono no bloqueante y ni siquiera son nuevos. Estos se ejecutan efectivamente como el bucle de eventos en Node. Si quieres comprobar qué tipo de velocidades se pueden obtener de estos, aquí hay un ejemplo de uno de los miembros del equipo central de ReactPHP, Cees-Jan Kiewiet. Spoiler: es rápido.

Nuevo tiempo de ejecución

Por lo tanto, no contamos Correcaminos y OpenSwoole ya que no son nuevos. Pero, ¿recuerdas cuando dije que la necesidad es la madre de la invención? Pues bien, este año se ha producido algo bastante sorprendente: el lanzamiento de un nuevo servidor de aplicaciones PHP, FrankenPHP.

¿Por qué se llama FrankenPHP? Porque la necesidad de evolución de PHP ha dado lugar a que el nuevo tiempo de ejecución se codifique en Go, de forma similar a Roadrunner, sólo que éste se construyó sobre el servidor web servidor web Caddy. ¿Tiene sentido? Quizás parezca extraño, así que no. ¿Es rápido? Sí. ¿Te importa que esté en Go? Esperemos que no. Aquí hay un ejemplo de FrankenPHP siendo utilizado por Laravel Octane. Spoiler: es rápido.

¿De dónde viene FrankenPHP?

Crédito de la imagen: FrankenPHP https://frankenphp.dev/

El creador de FrankenPHP es Kévin Dunglas. Lo que es interesante destacar es que Kévin es miembro del núcleo del Symfony Frameworkpor lo que se podría argumentar que Symfony ha patrocinado efectivamente la creación de un nuevo y más rápido tiempo de ejecución PHP al patrocinar su trabajo.

Sin embargo, hay otra razón para conocer el trabajo de Kévin, ya que también es el creador de Plataforma API.

Un momento, ¿qué es una plataforma API?

Crédito de la imagen: API Platform https://api-platform.com/

Ah, vale, me alegro de que preguntes. Bueno, PHP es tan legado que ahora puede utilizar un marco de backend a medida que está diseñado únicamente para el desarrollo rápido de API web REST/graphQL. Se puede utilizar con Symfony o Laravel, y contiene características tales como la selección de sus normas de respuesta de la API, la gestión automática de la documentación con OpenAPI o SwaggerUI, herramientas de pruebas automatizadas y el rendimiento / manejo de caché. ¿Prototipos de API web para producción?

Spoiler: es rápido.

Notas comunitarias: Cada vez más grandes

Foto: Asistentes a la DrupalCon Barcelona 2023

https://events.drupal.org/barcelona2024

Una frase común que me dicen todos los años los desarrolladores es que el uso de PHP (y por lo tanto el desarrollo de PHP) se reduce cada año. Esto coincide cada año con la publicación de la encuesta a desarrolladores de StackOverflow. Creo que es importante saber que la tan manida cifra de que el 70% (o más o menos) de la web es PHP se debe a WordPress. Sí, es PHP, pero es el éxito de WordPress como producto lo que hace que esa cifra sea así. Con una cifra tan inflada, sólo puede disminuir con el tiempo a medida que más y más frameworks CMS e incluso productos CMS SaaS Cloud como Contentful o Strapi aumenten su uso.

¿Está desapareciendo el uso de PHP? Numéricamente, sí, ya que los usuarios pasan de WordPress, pero las comunidades de PHP siguen siendo increíblemente fuertes. El uso de tres de sus principales frameworks está aumentando, lo que significa que se están desarrollando nuevos proyectos. DrupalCon cuenta con una media de 3.000 asistentes por conferencia, y se celebran varias al año en todo el mundo. SymfonyCon y Laracon también se celebran en todo el mundo, varias veces al año, con una media de entre 1.000 y 3.000 asistentes. Eso, para mí, no muestra un lenguaje moribundo. Muestra uno en crecimiento.

¿Quizá la gente empieza a darse cuenta?

Se dice que la imitación es la mejor forma de adulación. Con esa filosofía en mente, vale la pena señalar que el enfoque de Laravel para el desarrollo full-stack (a su vez basado originalmente en Rails) ha generado frameworks con todas las funciones fuera del espacio PHP. Conozca AdonisJSun framework Node basado en Laravel. ¿No es suficiente? Aquí tienes Wasp, también un Node Framework basado en Laravel. ¿Qué tal Goravel, un framework Go basado en... bueno, creo que ya sabemos lo que viene.

El enfoque específico de Laravel respecto a la experiencia del desarrollador es lo que le ha granjeado el favor de los desarrolladores. Tanto, de hecho, que el influenciador tecnológico ThePrimeagen enarcó una ceja al ver el vídeo de Aaron Francis PHP ya no apesta y lo comprobó. El resultado fue un respaldo inesperado. Una charla suya en LaraconUS este año remató esto hasta el momento en que Laravel anunció que habían recaudado 58 millones de dólares en capital de riesgo. Usted podría haber abordado este artículo pensando que PHP está muriendo, pero con este tipo de idas y venidas, yo diría que tal vez no.

El caso es que todo esto de los frameworks está muy bien, pero... ¿quién evoluciona el Lenguaje PHP?

La Fundación PHP

Con suerte, si no eres un desarrollador de PHP, entonces puede que haya captado tu atención en este artículo. Así que, un poco de antecedentes: durante años, PHP fue mantenido sólo por dos personas, Nikita Popov y Dmitry Stogova través del patrocinio de JetBrains y Zend respectivamente. Sí, hubo una cantidad decente de apoyo por parte de gestores de versiones demasiado numerosos para mencionarlos, pero eso sigue siendo mucho trabajo en las placas de dos desarrolladores para las características. En 2022, La Fundación PHP que actualmente tiene una junta formada por veteranos de PHP y representantes de Automattic, Zend, Private Packagist, JetBrains, Tideways, Perforce y Symfony.

La Fundación paga a 10 ingenieros, algunos a tiempo completo y otros a tiempo parcial. Es bastante raro tener este tipo de gobierno abierto, cuando lo más habitual es "dictador benevolente vitalicioo con respaldo comercial. Este viaje no puede continuar sin ellos, así que si quieres ver dónde continúa este viaje de 30 años, puedes consultar https://thephp.foundation/sponsor/ para ayudar al lenguaje en su próxima iteración.

Conclusión

No sé por qué estamos viendo un resurgimiento de "lolphp" por los rincones de Internet, pero francamente, no estoy exactamente preocupado. Creo, sin embargo, que está limitando un poco las habilidades de los desarrolladores cuando repiten como loros que algo es malo, lo que probablemente ha venido de alguien que probablemente escribió el lenguaje hace 15 años. PHP es moderno, tiene un aspecto totalmente diferente al de hace 15 años y cuenta con una próspera comunidad y un sistema de herramientas. Cosas como SalmoPHP y PHPStan análisis estático cortesía del Árbol de Sintaxis Abstracto, son herramientas absolutamente de primera clase. Si algunas de las mayores influencias tecnológicas están dispuestas a intentarlo, ¿por qué no tú? Puedes empezar a probar las comunicaciones de Vonage obteniendo el Vonage PHP SDKdel que soy el mantenedor principal. ¿Necesitas ayuda? Puedes unirte a nuestra comunidad Slack o ponte en contacto con nosotros en X. ¿Necesitas orientación? Puedes reservar una breve sesión conmigo.