- La mayoría de las críticas de que "PHP apesta (PHP Sucks)" vienen de no haber visto PHP desde 2012
- Ha habido muchos cambios desde PHP 5.4, y vale la pena revisar cómo ha evolucionado el lenguaje desde entonces
Cambios principales desde PHP 5.4
- Traits (PHP 5.4)
- Permiten usar composición en lugar de herencia
- Se pueden tener traits que se incluyan en cualquier clase
- Sintaxis corta de arreglos
- Se pueden usar corchetes sin necesidad de escribir
array()
- Desestructuración de arreglos
- Permite asignar valores directamente a variables sin tener que pasar antes por una variable temporal
- Funciones variádicas de primera clase
- Usando la sintaxis
..., se puede pasar a una función la cantidad de argumentos que se quiera
- Generadores
- Permiten realizar tareas intensivas de memoria de forma más eficiente
- Clases anónimas
- Permiten crear una clase nueva sin necesidad de crear un archivo nuevo
- También pueden implementar interfaces, igual que cualquier otra clase
Cambios principales desde PHP 7
- Comas finales
- Ya no hace falta preocuparse por agregar una coma final en llamadas a funciones o métodos
- Funciones flecha
- Son un poco distintas a las de JavaScript, pero han sido una buena adición al lenguaje
- Operador de fusión nula
- Ya no hace falta comprobar
null antes de asignar un valor
- Operador de asignación con fusión nula (PHP 7.4)
- También existe un operador de asignación abreviado para el operador de fusión nula
- WeakMap (PHP 7.4)
- Es mucho mejor para la memoria que los arreglos
- Permite usar objetos como claves
Cambios desde PHP 8
- Operador nullsafe
- Ya no hace falta comprobar
null antes de llamar a un método
- Argumentos nombrados
- Ya no hace falta usar
null para saltarse argumentos opcionales
- Atributos (anotaciones)
- Se pueden usar para añadir anotaciones a clases, métodos, argumentos o propiedades
- Mejor manejo de errores
- Ya no se necesitan variables de excepción para devolver
false
- Expresión
match
- Una forma más concisa y fácil de leer que las sentencias
switch largas
- Enums (PHP 8.1)
- Permiten crear clases enum con valores y métodos
- También se pueden usar como type hints
- Seguridad de tipos
- Incluye argumentos tipados, tipos de retorno, union types, intersection types y más
- También se pueden usar type hints para enums
- Promoción de propiedades en el constructor (PHP 8.0)
- Basta ya de constructores verbosos
- Ayuda a reducir el código boilerplate
- Propiedades de solo lectura (PHP 8.1)
- Se puede declarar una palabra clave para marcar propiedades como de solo lectura
Rendimiento
- Mejora de rendimiento del 400% al pasar de PHP 5.6 a 7
- Mejora de rendimiento del 20% al pasar de PHP 7 a 8
- Ofrece rendimiento suficiente para la mayoría de los usos de desarrollo web; si el caso es más especializado, se recomienda usar un lenguaje especializado
Conclusión
- PHP no ha muerto y ya no es de lo peor. El lenguaje ha cambiado bastante desde 2012, y ya es hora de actualizar esa opinión.
- Con la introducción de traits, la sintaxis corta de arreglos, la desestructuración de arreglos y muchas otras funciones, PHP se ha convertido en un lenguaje más eficiente, legible y fácil de mantener.
- Si a eso se le suma la mejora en el manejo de errores, la introducción de atributos y la llegada de los esperados enums, queda claro que PHP ha evolucionado hasta convertirse en una opción sólida y confiable para el desarrollo web.
- Así que, si alguien dice que PHP es lo peor, se puede decir con confianza que simplemente se quedó en el pasado.
Opinión de GN⁺
- Si se observan los cambios del lenguaje en PHP, queda claro que ya no es el PHP del pasado. Aun así, parece que muchos desarrolladores siguen aferrados a percepciones antiguas.
- Se han añadido muchas funciones que hacen el código más conciso y legible, como traits, la sintaxis short array y la asignación por desestructuración. Eso también parece contribuir a una mejor mantenibilidad.
- También destacan funciones como los generadores y WeakMap, que mejoran la eficiencia de memoria. Parecen útiles al procesar grandes volúmenes de datos.
- También ha habido cambios que elevan la madurez del lenguaje, como enums y mejoras en la seguridad de tipos. Se espera que faciliten escribir código más limpio.
- Sobre todo, la mejora de rendimiento en PHP 8 resulta impresionante. Se dice que en benchmarks reales muestra un rendimiento comparable al de NodeJS y Go.
- Sin embargo, modernizar proyectos legacy de PHP no es una tarea fácil. La migración de código puede requerir muchos recursos.
- PHP sigue siendo el lenguaje base de gran parte del ecosistema open source, incluyendo WordPress. Parece difícil menospreciar su valor fijándose solo en las características del lenguaje.
40 comentarios
Estos comentarios muestran muy bien por qué php todavía sigue siendo una porquería.
Felicidades por convertirse en una mierda que ya no apesta.
Si tienen la oportunidad, ojalá prueben comer otra cosa en vez de mierda : )
Se están publicando muchísimas opiniones. Yo no soy desarrollador de PHP. Al ver el odio hacia PHP que se ha alimentado en la comunidad, parece que las personas junior terminan adoptando ese sentimiento y el círculo vicioso se repite. Un artesano jamás le echa la culpa a sus herramientas. Mucho ánimo siempre para quienes desarrollan en PHP.
Como desarrollador de PHP... la arrogancia de la gente que usa otros lenguajes de verdad da ganas de mentar madres.
No entiendo por qué tienen tanta necesidad de menospreciar el lenguaje que usan otros.
Yo también, después de desarrollar con PHP, me cambié a Java, probé Python y también Node.js, pero...
Cada lenguaje tiene su propia filosofía difícil de entender o sus incomodidades, así que no entiendo por qué están tan desesperados por tirarle hate solo a PHP.
Carajo, no entiendo por qué son así...
Esas situaciones que llaman bugs de PHP, cuando realmente te pones a desarrollar,
son sintaxis o estructuras que casi no se usan aunque no las conozcas,
y ese tipo de legado también existe hasta cierto punto en otros lenguajes.
Ya me tiene hartísimo.
Me disculpo por haber hablado sobre la tecnología a la que te dedicas. Independientemente de mi intención, el resultado fue que herí los sentimientos de koxel, y eso es mi responsabilidad.
Dicho eso, solo escribí lo que sentí al trabajar como junior entre desarrolladores de PHP que creen que programar al aire es todo. Algunos desarrolladores de PHP ni siquiera reconocen que las mejores prácticas cambian y se niegan a aceptarlo. Eso me frustraba. Actualmente, por mi situación, trabajo principalmente en el sector frontend, pero también creo que hay mucho que criticar sobre las formas de desarrollo en JavaScript. No creo que ningún lenguaje tenga una superioridad absoluta, y creo que según la situación deben aplicarse criterios diferentes.
Pensándolo bien, parece que el problema es la estructura que permite que un desarrollador principiante escriba mal un programa.
Pero ¿eso no pasa igual en todos los demás lenguajes?
Para eso existen las llamadas mejores prácticas en cada lenguaje...
Según WordPress, la tasa de uso de PHP 5.6 o versiones anteriores es menor al 5%.
https://wordpress.org/about/stats/
Aun así, en 2023 WordPress elevó el requisito mínimo de instalación de PHP a 7.0.
En lo personal, diría que detesto PHP casi al mismo nivel que detesto Javascript.
Comparados con esos dos, hasta Python parece un ángel.
Empecé mi carrera con php, y creo que también alcancé mi punto más alto en la carrera gracias a php.
Ahora me gano la vida con otros lenguajes, pero
Todavía saco php de vez en cuando para proyectos paralelos o hobbies.
Igual, me sigue pareciendo un lenguaje con mucho encanto.
Claro, últimamente han salido varias alternativas, así que da un poco de pena, pero
laravel vaporestá bastante bienAhora mismo no estoy haciendo desarrollo web, pero me trae recuerdos de antes.
Veo que a muchas personas no les gusta PHP. Yo también lo usé unos 3 años y durante todo ese tiempo pensé que, como lenguaje, realmente le faltaba mucho atractivo; de hecho, creo que PHP fue una de las razones por las que, al conocer RoR, terminé enamorándome de la elegancia del lenguaje Ruby.
Pero cuando PHP salió por primera vez, ¡fue impresionante! En esa época todavía se hacían foros con CGI. La agilidad que ofrecía PHP en ese entonces fue sensacional. Sí parece cierto que PHP abrió un gran horizonte para el desarrollo web. :)
Pero el vino nuevo va en odres nuevos...
PHP como lenguaje sigue siendo de lo peor,
pero como plataforma (me cuesta encontrar la palabra adecuada) creo que PHP es bastante mejor de lo que uno pensaría.
Sobre todo en proyectos MVP o en etapa inicial de crecimiento, si desde el principio dejas claro que más adelante se va a migrar a otro lenguaje/plataforma/framework (por lo general Spring),
después de eso los defectos del lenguaje dejan de ser lo importante y solo empiezan a destacar las ventajas de PHP.
Como se puede desplegar simplemente modificando archivos sin interrupciones, se puede reflejar más rápido el feedback de los usuarios,
y el manejo eficiente y austero de la cola de solicitudes que PHP(-FPM) hace especialmente bien frente a otras opciones le permite aguantar bastante bien picos inesperados de tráfico (crecimiento de corto plazo),
aunque haya bugs, toda la app no se cae, y como también está relativamente a salvo de las fugas de memoria, uno puede concentrarse en la lógica de negocio +a,
y hasta desarrolladores cuyo lenguaje principal es otro y que nunca han usado PHP pueden, con una semana de práctica, llegar a manejarlo razonablemente por su baja dificultad...
Todo esto se convertirá en desventajas cuando el tamaño crezca (quizás incluso graves), pero...
al menos a escala de MVP, en una situación donde hay que tomar el feedback de los usuarios, implementarlo rapidísimo y crecer con velocidad, ¿hay realmente una opción más adecuada que PHP?
Además, como al decidir adoptar PHP ya se parte de la idea de que "si crece de tamaño, migraremos a otro lenguaje", entonces, seriamente... Why not?
Pienso un poco distinto: si uno quiere crear un MVP por su cuenta, necesita una herramienta que le permita implementar el esquema de la BD, el WAS y la UI con la mínima cantidad de código posible. Y creo que, como alternativas a PHP, hay excelentes opciones como Ruby on Rails y Django.
En el caso de Django, si defines solo la clase del modelo con el patrón Active Record (qué término tan anticuado, la verdad), obtienes el esquema de la BD y una UI CRUD de back office bastante usable. También ofrece herramientas mínimas para desarrollar un servicio web, como autenticación, control de acceso, validación de formularios, herramientas de migración de BD y herramientas de pruebas. En lo personal, desde que empecé a programar para la web a fines de los 2000, nunca he experimentado una productividad como la de Django. Desde que se puso de moda el enfoque SPA y se separaron los roles de frontend y backend, incluso siento que la productividad más bien disminuyó. Eso se debe a que, para poder trabajar en paralelo, al menos dos personas tienen que entender el flujo de usuario y trabajar con el protocolo ya alineado.
Si PHP quería presentarse como un lenguaje de plantillas para aplicaciones web, creo que debería haber proporcionado a nivel de lenguaje medios para defenderse de las vulnerabilidades web. Me parece que el hecho de que el estilo moderno de PHP haya adoptado un enfoque de desarrollo basado en frameworks puede verse como prueba de ello.
Y hace mucho tiempo que php dejó de presentarse como un lenguaje de scripting de propósito general.
No entiendo por qué comparan un lenguaje con un framework.
Está Laravel, que tiene conceptos de Ruby on Rails y Django.
Cuando
modernphpdeje de ser algo "moderno" y se establezca como la forma estándar de desarrollo en PHP, y cuando los CMS, incluido WordPress, adoptenmodernphp, creo que la gente percibirá a PHP como un lenguaje de propósito general seguro. Recuperar la confianza por lo general requiere más esfuerzo que romperla.Porque, con el pretexto de mantener la compatibilidad hacia atrás, se permite que quienes empiezan construyan servicios web inseguros usando solo las funciones básicas de PHP. Entre los 5 primeros sitios que aparecen al buscar
PHP tutorial, aparte del sitio oficial de PHP, no hay casos que incluyan que, para prevenir XSS, se debe aplicar escape de HTML al mostrar el contenido de una superglobal. Si la guía que ellos ofrecen oficialmente contiene temas de desarrollo web, ¿no significa eso que PHP está cumpliendo dos roles, el de lenguaje y el de framework?¿Qué opinan sobre el hecho de que varios elementos de HTTP se ofrezcan de forma predeterminada mediante los nombres de las superglobales? Yo creo que el alcance de la generalidad y los casos de uso se determinan según lo que expresa el lenguaje.
Los superglobales que mencionaste como ejemplo, como
$_GETy$_POST, son valores expuestos cuando PHP se usa en modo CGI o SAPI. Si PHP se usa desde CLI, esos valores no se exponen.Esos superglobales son una especie de API expuesta por tiempos de ejecución que ejecutan PHP, como PHP-CGI o PHP-FPM, no parte de la especificación de PHP como lenguaje.
Lo de “PHP que se presenta como lenguaje de plantillas” mencionado antes, estrictamente hablando, tampoco es PHP, sino que uno de sus runtimes, CGI, es el que busca que se use de esa manera.
Del mismo modo, las numerosas funciones internas de PHP de las que se hablaba como vulnerabilidades también son funciones expuestas por extensiones de PHP, no capacidades que pertenezcan al “lenguaje” PHP en sí.
Si seguimos tu planteamiento,
JavaScript sería un lenguaje y también un framework diseñado desde el inicio para usar las APIs que expone el navegador para comunicarse con él,
Java sería un lenguaje, pero en la práctica también un framework usado para aprovechar las numerosas APIs del JDK,
y todos los demás lenguajes, independientemente de la especificación del lenguaje en sí, si proporcionan bibliotecas estándar o APIs, entonces también tendrían que considerarse frameworks.
Claro que la relación entre esas cosas es inseparable, pero usar ese punto para afirmar que PHP es un framework resulta poco convincente.
Y aun viendo que, hasta mayo de 2024, se siguen parchando XSS en el proyecto core de WordPress, parece que no es posible impedir XSS solo con mejoras a nivel de la sintaxis de PHP.
Los frameworks de frontend y los motores de plantillas del lado del servidor aplican de forma uniforme el escape de HTML a todo lo que puede renderizarse como datos, y solo generan salida de forma insegura cuando el escape se desactiva explícitamente. En PHP no existe un método consensuado para aplicar ese tipo de manejo de forma general. Si
echooprinthubieran soportado escape por defecto, al principio habría aparecido una gran cantidad de código que dejaría de funcionar, pero a largo plazo probablemente muchas personas habrían cometido menos errores por omitir el escape.Sí, no estoy de acuerdo con la perspectiva de separar el lenguaje y el entorno de ejecución, y creo que de una u otra forma el entorno de ejecución influye en el lenguaje. En el caso de JavaScript, existen dos entornos de ejecución, Node.js y el navegador, y en Python hay muchas implementaciones, pero podría decirse que CPython es la dominante.
El tema del artículo original se limita a las mejoras sintácticas, pero yo quería hablar de algo dentro de un marco un poco más amplio que ese.
> Además, creo que Laravel debería haber surgido no como aporte de la comunidad open source, sino por parte de empresas como la de Rasmus o Zend, y no alrededor de 2011 sino hacia 2007, no como un proyecto independiente sino como una funcionalidad oficial del lenguaje. Aunque la adopción de Python 3 tuvo tropiezos porque sacrificó parte de la compatibilidad hacia atrás, también creo que PHP debió haber hecho una gran limpieza de compatibilidad hacia atrás alrededor de la versión 5. A veces da la impresión de que los cambios en PHP siempre llegan con retraso respecto al curso de los tiempos.
Esto también sirve como respuesta al comentario de arriba.
Visto desde la perspectiva que mencionas, sí me hace pensar que se podría tratar a PHP como una especie de framework web.
Aun así, no creo que PHP tenga que ofrecer por defecto varias de las funciones que mencionas como ejemplo, incluyendo filtro XSS, escape, etc.
El muy común PHP-FPM no está en la misma posición que Django o RoR. Más bien se parece a Flask, Sinatra o Express.
PHP-FPM no se encarga de más que enrutamiento (basado en directorios), interpretación de la solicitud (
$_GET,$_POST,$_FILE,$_COOKIE), envío de la respuesta (echo,print) y manejo de sesiones ($_SESSION).¿Flask es distinto?
En Flask, para devolver una respuesta con HTML escapado no se resuelve simplemente con hacer
return.https://flask.palletsprojects.com/en/3.0.x/quickstart/#html-escaping
¿Sinatra es distinto?
Igual, hay que usar una librería de escape aparte.
https://sinatrarb.com/faq.html#escape_html
¿Express es distinto?
También pasa lo mismo: hay que usar una librería de escape aparte.
https://expressjs.com/en/resources/middleware.html
Ninguna de las librerías puestas como ejemplo es una librería provista oficialmente por esos frameworks.
Entonces, ¿por qué PHP sí tendría que ofrecer oficialmente ese tipo de funciones?
Si alguien dice que PHP es basura por razones de las que ya ha hablado mucha gente, como
"¿qué clase de framework loco expone los datos de la petición como variables superglobales?, aunque no haya un problema de seguridad, ¡eso ya es una falta de respeto hacia el usuario!",
bueno, eso lo entendería;
pero la razón que mencionas de que "las funciones básicas de PHP no son tan suficientes como las que ofrece un framework full-stack"... al menos a mí me cuesta estar de acuerdo.
Así como existe un amigo llamado Nestjs para usar Express de una forma más moderna y estructurada, se puede pensar que existe un amigo llamado Laravel para usar PHP de una forma más moderna y estructurada...
¿No se sentirán más las ventajas propias de PHP(-FPM), tal como decía mi comentario original, que las desventajas que aparecen al compararlo con otros frameworks (lenguajes)?
Pensando en mis recuerdos, creo que al menos si la combinación de Slim y Twig se hubiera popularizado, habría podido reducir los errores de PHP que cometí en proyectos. Claro, en ese entonces no se podía introducir porque otros desarrolladores de PHP ya estaban acostumbrados a programar PHP de forma muy artesanal. Por suerte, PDO estaba en la biblioteca estándar, así que sí se podían tomar medidas contra la inyección SQL.
Sobre la limitación del impacto de los bugs o el rendimiento de procesamiento que mencionaste en el comentario original, no tengo una opinión particularmente negativa ni positiva. Sí me parece una función que estaría bien tener, pero los problemas de aumento explosivo del throughput o del uso de memoria son cuestiones que, en la etapa de crecimiento, hay que considerar al menos una vez, así que creo que es mejor que ese tipo de problemas aparezcan lo antes posible de forma explícita.
> Claro, en ese momento no se podía introducir porque otros desarrolladores de PHP estaban acostumbrados a programar PHP de forma artesanal.
> Porque lo que más tiempo toma y lo más difícil es cambiar a la gente que sabe desarrollar con PHP
Personalmente, creo que PHP en sí no tiene problemas, o que existen medios suficientes para responder a ellos, o que como en otros lenguajes solo hay diferencias que surgieron por razones comprensibles. Pero ese problema de personal que mencionas... me parece que en realidad ese es el problema más grande.
Los desarrolladores capaces de usar PHP en serio ya se hartaron hace mucho del PHP de antes y escaparon de PHP hace tiempo,
y la mayoría de los usuarios que quedan son personas que, por más que PHP mejore, no lo valoran como corresponde, o no tienen margen para valorarlo como corresponde...
En proyectos MVP+a donde se considera que PHP es adecuado, no hay razón para que participen esos profesionales con experiencia del primer grupo,
y aunque participaran, o no elegirían PHP, o incluso si eligieran PHP, en el momento en que se meta una o dos personas del segundo grupo, aquello se volvería un desastre... jaja
Al menos aquí en Corea, no es fácil conseguir personal capaz de hacer un desarrollo PHP satisfactorio.
Y así, una vez más, PHP queda fuera de las opciones, baja todavía más el nivel promedio del talento disponible, y eso se repite infinitamente, creando un círculo vicioso.
~~Aunque sea así, habría que seguir vendiéndolo para que, al menos en proyectos pequeños de 1 a 3 personas,~~ aumenten los casos en que se intenta hacer proyectos PHP de verdad; solo así se podría romper ese círculo vicioso.
Y eso que yo mismo, en realidad, tampoco genero tantas ganancias con PHP. Como es tan difícil conseguir personal satisfactorio, la realidad es que no puedo adoptar PHP como stack principal aunque quisiera...
Esto se debe a que hay una diferencia en la forma de generar páginas HTML entre los lenguajes de propósito general y PHP. Flask, al menos desde el lanzamiento de la versión 1.0, ha fomentado que la gente use un motor de plantillas y fue diseñado para depender de uno. Ha separado intencionalmente las páginas HTML de los datos del lado del servidor y ha apoyado el trabajo a nivel de plantillas. Creo que ahí se toman en cuenta las características del problema que se quiere resolver y los hábitos de uso de la gente.
En cambio, en PHP la salida estándar pasa a ser parte de la página y el límite entre los datos del lado del servidor y la página HTML es difuso. Lo que se hace con
printentra tal cual en la página resultante, y el escape debe hacerlo explícitamente el desarrollador. Un diseño en el que hay que aplicar la funciónhtmlcharacterescapesa todos los datos externos no fue bien recibido por la gente. La gente quería plantillas de manera inconsciente, pero da la impresión de que en PHP no se consideró el objetivo del usuario de generar páginas HTML.La razón por la que esa funcionalidad debe venir en la biblioteca estándar o incluso en el propio lenguaje es que, al considerar la configuración del entorno y la forma de desplegar código en PHP, ese es el método más efectivo. El entorno de desarrollo está estandarizado con el stack LAMP, el entorno de operación con el esquema de web hosting, y como la gente está acostumbrada a subir archivos por FTP, la posibilidad de ofrecer paquetes adicionales es menor que en un lenguaje de propósito general. Tampoco se puede exigir a los principiantes que instalen módulos. La única opción que queda es la biblioteca estándar y la documentación oficial.
> La gente inconscientemente quería plantillas, pero en PHP parece que no se tuvo en cuenta el objetivo del usuario de generar páginas HTML.
No me parece que sea algo con lo que se pueda estar muy de acuerdo.
Se podría decir que en la época de PHP3, cuando apenas estaba al nivel de exponer fácilmente una API de C como CGI, sí se usaba con fines de plantilla, como mencionas, pero...
Desde PHP 4.2 ya existía un entorno lo suficientemente maduro como para darle un uso de propósito general.
Se convirtió en un entorno donde se podía esperar que el código se ejecutara mediante CLI y, como mencionaste en el comentario anterior, decir que "Laravel debió haber aparecido alrededor de 2007 no como un proyecto individual sino como una funcionalidad oficial del lenguaje" es algo que no encaja en absoluto con la dirección que tenía PHP en ese momento.
La existencia de Smarty, un motor de plantillas para PHP publicado en 2004, y de CodeIgniter, un framework MVC para PHP publicado en 2006, demuestra justamente que PHP en sí no era un lenguaje de plantillas; y también permite pensar que ya existía un consenso social dentro de la comunidad de PHP de que no debía usarse así.
> Los frameworks de frontend, los motores de plantillas del lado del servidor, etc., aplican escape de HTML de forma uniforme a todo lo que puede renderizarse a partir de datos, y solo generan salida de forma insegura cuando se desactiva explícitamente ese escape.
Tampoco creo que lo anterior de tu comentario previo sea del todo correcto si se compara con la cronología de PHP.
Desde que django se publicó por primera vez en 2005, y durante varios años después, el escape de HTML no venía activado por defecto. El desarrollador tenía que configurar intencionalmente un filtro de escape. Incluso hoy, en el caso de jinja, que sigue usándose en Python, el escape de HTML todavía no se procesa automáticamente.
Para cuando el escape automático ya se consideraba algo normal, PHP hacía mucho que había dejado atrás la identidad de lenguaje de plantillas. (Puede que los usuarios que usaban PHP de forma irreflexiva en esa época no lo quisieran, pero visto de otra manera, también podría decirse que PHP ya había decidido ir excluyendo lentamente a ese tipo de usuarios).
Como PHP ya no es un lenguaje para ese tipo de propósito, no hay ninguna razón para aplicar ese tipo de funcionalidad como valor por defecto en la biblioteca estándar y en el lenguaje; y desde la perspectiva de PHP, que busca funcionar como un lenguaje de propósito general, creo que la función
htmlcharacterescapesya cumplía suficientemente bien ese papel.> Como el entorno operativo está estandarizado en torno al modelo de web hosting y la gente está acostumbrada a subir archivos por FTP, la posibilidad de ofrecer paquetes adicionales es menor que en los lenguajes de propósito general.
Tampoco me resulta fácil coincidir mucho con eso. Desde hace más de una década se ha usado bastante bien
gity herramientas similares. Incluso desde poco después de que se publicara Docker, ya se intentaba desplegar bastante usando Docker, y todavía hoy se sigue usando así.Creo que la mayoría de las cosas que mencionas tienen sentido no tanto para PHP, sino más bien cuando uno se mueve sobre CMS desarrollados en PHP.
No me gusta mucho usar esta expresión, pero serían esos casos en los que ni siquiera tratan a los desarrolladores de PHP como desarrolladores...
La función de escape automático de jinja demuestra que mi afirmación era incorrecta y que lo que mencionaron es correcto.
> También me cuesta mucho coincidir con lo anterior. Desde hace más de una década ya se aprovechaban muy bien herramientas como git. Incluso justo después de que se publicara Docker, ya se intentaba bastante hacer despliegues usando Docker, y todavía hoy se sigue usando de esa manera.
Mi experiencia con PHP se quedó en 2014, y en ese entonces no existía Docker. Tampoco se podía introducir git porque había que cambiar la forma de trabajar. En la práctica, para introducir ese tipo de cosas en un entorno laboral tiene que haber consenso, y en mi situación eso era imposible.
> No me gusta este tipo de expresiones, pero esos casos en los que ni siquiera tratan a los desarrolladores de PHP como desarrolladores...
Ahora que lo pienso, supongo que trabajé entre personas a las que no trataban como desarrolladores.
Los ejemplos que mencionaste de Django —autenticación, control de acceso, validación de formularios, herramientas de migración de BD y herramientas de pruebas— también están todos disponibles en Laravel de PHP.
Autenticación: https://laravel.com/docs/11.x/authentication
Control de acceso: https://laravel.com/docs/11.x/authorization
Validación de formularios: https://laravel.com/docs/11.x/validation
Migraciones de BD: https://laravel.com/docs/11.x/migrations
Pruebas: https://laravel.com/docs/11.x/testing
Además, aunque son bibliotecas externas o de pago,
también existen herramientas que exportan el esquema de una BD existente a modelos y código de migración, o que funcionan al revés,
y también existe https://nova.laravel.com/, que ofrece un backoffice limpio con UI CRUD incluida.
Casi todas las funcionalidades que tiene Django también existen en Laravel.
(Desde el principio, como ambos heredaron el concepto de RoR, creo que era inevitable que las funciones ofrecidas fueran similares.)
Aun así, a diferencia de Django-Python, Laravel-PHP además tiene las ventajas que mencioné en mi comentario original.
No se puede negar que PHP fue diseñado como un lenguaje orientado a plantillas para aplicaciones web,
pero a estas alturas, cuando ya casi han pasado diez años desde que se estableció el estilo moderno de PHP, me parece injusto seguir viéndolo simplemente como un lenguaje de plantillas.
Vi que enlazaron Nova y lo revisé, pero esto también tiene licencia de pago. Aunque en el tutorial del proyecto se indique explícitamente y pueda usarse de inmediato, y quizá sus funciones sean similares a las de Django Admin, parece haber una diferencia en términos de accesibilidad.
Además, creo que Laravel es algo que debería haber salido como una función oficial del lenguaje, no como un proyecto individual, hacia 2007 y no en 2011, impulsado no por colaboradores de código abierto sino por empresas como Rasmus o Zend. Python 3 tuvo dificultades de adopción porque renunció parcialmente a la compatibilidad hacia atrás, pero también creo que PHP debió haber hecho una gran limpieza de compatibilidad hacia atrás alrededor de la versión 5. Da la impresión de que los cambios de PHP siempre llegan con cierto desfase respecto al curso de los tiempos.
Ahora, personalmente, como ya no estoy en la etapa de iniciarme en el desarrollo web, no habrá ocasión en la que elija PHP
Sigues confundiendo el lenguaje con el framework.
No creo que sea necesario publicar el mismo contenido como comentario en varios lugares. ¿Quiere llamar la atención?
Obviamente ha mejorado comparado con antes, pero a estas alturas, si voy a usar PHP, da la impresión de que Node.js o Python tienen más usos versátiles.
Se viene el boom de PHP
No se menciona en absoluto cuánto ha mejorado en 10 años el ecosistema de PHP, su forma de despliegue, su modelo de ejecución y sus métodos de depuración. Como lo que más tiempo toma y lo más difícil es que cambie la gente que sabe desarrollar con PHP, ni siquiera espero particularmente que vaya a mejorar. En especial, como la publicación enlazada es un blog de marketing de un freelance de PHP, parece que hay que tomarla con filtro aún mayor.
Durante los últimos 10 años, según las estadísticas de uso de PHP basadas en paquetes de Composer (distribución similar a npm de Node), PHP 5 o inferior prácticamente desapareció, y el ecosistema de PHP hace tiempo que se trasladó a un modelo centrado en Composer.
Algunos CMS como WordPress, Gnuboard y otros están completamente desconectados de eso.
Exceptuando los CMS, el ecosistema está en una situación como la descrita arriba.
Desde la perspectiva de alguien que usa PHP, PHP sigue siendo el peor lenguaje.
Es que los otros lenguajes han mejorado más.
Opinión de Hacker News
Resumen:
fopen()PHP: ya no es un fractal de mal diseño
Documento de hace 12 años jajaja
Siguen citando un documento escrito en 2012....
¿De verdad creen que PHP siguió sin evolucionar y se quedó exactamente como en esa época de 2012..?
Aunque claro, no se puede negar que sí fue un lenguaje que empezó sin mucha base. jaja
Este es el enlace a la traducción del documento en inglés mencionado..
Por más malo que haya sido PHP, no creo que todavía arrastre los problemas de aquella época.
Incluso si lo mantienes, ya es un problema. Si el diseño ya está mal desde este nivel, ¿que haya mejorado la calidad por actualizar de versión? Eso es un problema porque rompe gravemente la compatibilidad hacia atrás. Hasta los operadores de comparación son raros, así que ¿qué se le va a hacer?
Parece que simplemente proporcionó una traducción al coreano del cuarto enlace del resumen de Hacker News jaja