- La plupart des critiques du type « PHP est nul (PHP Sucks) » viennent du fait qu’elles n’ont pas regardé PHP depuis 2012
- De nombreux changements ont eu lieu depuis PHP 5.4, et il faut examiner l’évolution du langage depuis lors
Principaux changements depuis PHP 5.4
- Traits (PHP 5.4)
- Permettent d’utiliser la composition plutôt que l’héritage
- On peut disposer de traits intégrables dans n’importe quelle classe
- Syntaxe courte des tableaux
- Permet d’utiliser des crochets sans avoir à écrire
array()
- Déstructuration de tableaux
- Permet d’assigner directement des valeurs à des variables sans passer par une variable temporaire
- Fonctions variadiques de première classe
- La syntaxe
... permet de transmettre autant d’arguments que souhaité à une fonction
- Générateurs
- Permettent d’effectuer des tâches gourmandes en mémoire de manière plus efficace
- Classes anonymes
- Permettent de créer une nouvelle classe sans devoir créer un nouveau fichier
- Peuvent implémenter des interfaces comme n’importe quelle autre classe
Principaux changements depuis PHP 7
- Virgule finale
- Il n’est plus nécessaire de se soucier d’ajouter une virgule finale dans les appels de fonctions ou de méthodes
- Fonctions fléchées
- Un peu différentes de celles de JavaScript, mais c’est un bon ajout au langage
- Opérateur de coalescence des nuls
- Évite d’avoir à vérifier
null avant d’assigner une valeur
- Opérateur d’affectation par coalescence des nuls (PHP 7.4)
- Il existe aussi un opérateur d’affectation raccourci pour la coalescence des nuls
- Weak maps (PHP 7.4)
- Bien plus avantageuses pour la mémoire que les tableaux
- Permettent d’utiliser des objets comme clés
Changements depuis PHP 8
- Opérateur de chaînage null-safe
- Évite d’avoir à vérifier
null avant d’appeler une méthode
- Arguments nommés
- Évitent d’avoir à utiliser
null pour sauter des arguments optionnels
- Attributs (annotations)
- Peuvent être utilisés pour ajouter des annotations à des classes, méthodes, arguments ou propriétés
- Gestion des erreurs améliorée
- Il n’est plus nécessaire d’avoir une variable d’exception pour retourner false
- Expression
match
- Une façon plus concise et plus lisible qu’un long
switch
- Enums (PHP 8.1)
- Permettent de créer des classes enum avec des valeurs et des méthodes
- Peuvent aussi servir d’indications de type
- Sécurité de typage
- Inclut les arguments typés, les types de retour, les union types, les intersection types, etc.
- Les enums peuvent aussi être utilisées dans les indications de type
- Promotion des propriétés du constructeur (PHP 8.0)
- Fini les constructeurs verbeux
- Aide à réduire le code boilerplate
- Propriétés en lecture seule (PHP 8.1)
- Possibilité de déclarer un mot-clé pour marquer des propriétés comme en lecture seule
Performances
- Gain de performances de 400 % entre PHP 5.6 et PHP 7
- Gain de performances de 20 % entre PHP 7 et PHP 8
- Des performances suffisantes pour la plupart des usages en développement web ; pour des usages plus spécialisés, il est recommandé d’utiliser un langage dédié
Conclusion
- PHP n’est pas mort et n’est plus le pire. Le langage a énormément changé depuis 2012, et il est temps de revoir son jugement.
- Avec l’introduction de fonctionnalités comme les traits, la syntaxe courte des tableaux ou la déstructuration, PHP est devenu un langage plus efficace, plus lisible et plus facile à maintenir.
- Si l’on ajoute l’amélioration de la gestion des erreurs, l’arrivée des attributs et celle, longtemps attendue, des enums, il devient clair que PHP est devenu un choix solide et fiable pour le développement web.
- Donc si quelqu’un dit que PHP est le pire, on peut lui répondre avec assurance qu’il est simplement resté bloqué dans le passé.
L’avis de GN⁺
- Les évolutions du langage montrent bien que PHP n’est plus celui d’autrefois. Pourtant, beaucoup de développeurs semblent encore rester sur cette ancienne perception.
- De nombreuses fonctionnalités ont été ajoutées pour rendre le code plus concis et plus lisible, comme les traits, la syntaxe short array ou l’affectation par déstructuration. Cela devrait aussi améliorer la maintenabilité.
- Des fonctionnalités comme les générateurs ou les weak maps, qui améliorent l’efficacité mémoire, attirent aussi l’attention. Elles semblent utiles pour le traitement de gros volumes de données.
- Il y a aussi eu des changements qui renforcent la maturité du langage, comme les enums ou l’amélioration de la sécurité de typage. On peut s’attendre à ce qu’il soit plus facile d’écrire du code propre.
- Surtout, l’amélioration des performances dans PHP 8 est impressionnante. Selon l’article, des benchmarks réels montreraient des performances comparables à NodeJS et Go.
- En revanche, moderniser des projets PHP legacy reste une tâche difficile. La migration du code peut demander beaucoup de ressources.
- PHP reste encore le langage de base de nombreux écosystèmes open source, dont WordPress. Il semble difficile de dénigrer sa valeur en ne regardant que ses caractéristiques de langage.
40 commentaires
Voilà des commentaires qui montrent bien pourquoi php craint encore.
Félicitations, c’est devenu une merde qui ne pue pas.
Si vous en avez l’occasion, essayez aussi autre chose que de la merde : )
Il y a vraiment énormément de réactions. Je ne suis pas développeur php. En voyant le rejet de php entretenu par la communauté, j’ai l’impression que les juniors finissent par développer ce genre de sentiment, et que le cercle vicieux se répète. Un artisan ne blâme jamais ses outils. Courage à tous les développeurs php, tenez bon.
En tant que développeur PHP... l’arrogance des gens qui utilisent d’autres langages me donne vraiment envie de jurer.
Je ne comprends absolument pas pourquoi ils tiennent tant à rabaisser les langages que les autres utilisent.
Moi aussi, après avoir développé en PHP, je suis passé à Java, j’ai aussi fait du Python et du Node.js, mais...
chaque langage a sa propre philosophie incompréhensible ou ses propres aspects pénibles, alors je ne comprends pas pourquoi tout le monde est obsédé par l’idée de critiquer PHP.
Putain, pourquoi ils font ça —
Les situations qu’on appelle des bugs de PHP, quand on développe réellement,
ce sont le plus souvent des syntaxes ou des structures qu’on utilise presque jamais, même sans les connaître,
et ce genre de legacy, tous les autres langages en ont aussi plus ou moins.
J’en ai vraiment ras le bol.
Je vous présente mes excuses pour avoir parlé de la technologie qui constitue votre métier. Indépendamment de mon intention, le résultat a été de blesser koxel, et cela relève donc de ma responsabilité.
Cela dit, je n’ai fait qu’écrire ce que j’ai ressenti en travaillant comme junior parmi des développeurs PHP qui pensaient que le code à l’arrache était tout ce qu’il fallait. Certains développeurs PHP refusent même d’admettre, et rejettent, le fait que ces bonnes pratiques évoluent. C’est ce qui m’a frustré. Actuellement, je travaille surtout dans le secteur du front-end, mais je pense qu’il y a tout autant de points critiquables dans la manière de développer en JavaScript. Je ne pense pas qu’un langage ait une supériorité absolue, et je pense qu’il faut appliquer des critères différents selon les situations.
En y repensant, il semble que le vrai problème soit la structure qui permet aux développeurs débutants d’écrire de mauvais programmes.
Mais ce n’est pas pareil dans les autres langages aussi ?
S’il existe des bonnes pratiques propres à chaque langage, c’est bien pour cette raison..
Selon WordPress, la part d’utilisation de PHP 5.6 et des versions inférieures est inférieure à 5 %.
https://wordpress.org/about/stats/
Malgré cela, en 2023, WordPress a relevé à 7.0 la version minimale requise pour les installations PHP.
Personnellement, je déteste PHP presque autant que JavaScript.
À côté de ces deux-là, Python paraît presque sympathique.
J’ai commencé ma carrière avec PHP, et j’ai sans doute aussi atteint un cap dans ma carrière grâce à PHP.
Aujourd’hui, je gagne ma vie avec d’autres langages, mais
je ressorts encore parfois PHP pour des side projects ou par hobby.
Je trouve que ça reste un langage séduisant.
Bien sûr, c’est un peu dommage qu’il y ait tant d’alternatives intéressantes ces temps-ci, mais
Laravel Vapor est pas mal.
Je ne fais plus de développement web en ce moment, mais... cela me rappelle des souvenirs.
Beaucoup de gens n'aiment pas PHP. Moi aussi, après l'avoir utilisé pendant environ trois ans, j'ai longtemps pensé que, comme langage, il manquait vraiment d'attrait. Et en découvrant RoR, je me suis complètement pris de passion pour l'élégance du langage Ruby — on peut presque dire que c'est PHP qui m'y a conduit.
Mais quand PHP est apparu pour la première fois, c'était énorme ! À l'époque, on codait des forums en CGI. La réactivité que PHP apportait alors était sensationnelle. Il me semble certain que PHP a ouvert de vastes horizons au développement web. :)
Mais à vin nouveau, outres neuves...
En tant que langage, PHP reste malgré tout le pire,
mais en tant que plateforme (j’ai du mal à trouver la bonne expression), je pense que PHP est meilleur qu’on ne l’imagine.
Surtout pour les projets entre le MVP et le début de la phase de croissance, à partir du moment où l’on pose clairement qu’on migrera plus tard vers un autre langage/une autre plateforme/un autre framework (généralement Spring),
les défauts du langage cessent ensuite d’être essentiels, et seuls les avantages de PHP sautent aux yeux.
Comme on peut déployer sans interruption simplement en modifiant les fichiers, on peut intégrer plus vite les retours des utilisateurs,
et la gestion très économe de la file d’attente des requêtes, dans laquelle PHP(-FPM) excelle particulièrement par rapport aux autres, permet de bien encaisser un trafic massif imprévu (croissance sur une courte période),
et même s’il y a des bugs, toute l’application ne tombe pas, tout en étant relativement à l’abri des fuites mémoire, ce qui permet de se concentrer sur la logique métier + a,
sans parler du faible niveau de difficulté : même des développeurs dont le langage principal est un autre et qui n’ont jamais utilisé PHP peuvent, après une semaine à regarder le code, s’en servir à peu près correctement...
Tout cela se transformera en inconvénients quand l’échelle augmentera (peut-être même en inconvénients graves)...
Mais au moins à l’échelle d’un MVP, dans une situation où il faut prendre les retours utilisateurs, les implémenter en vitesse et croître rapidement, existe-t-il vraiment une option plus adaptée que PHP ?
Et comme, au moment de décider d’adopter PHP, on est déjà dans l’état d’esprit de se dire « quand ça grossira, on migrera vers un autre langage », alors sérieusement... Why not ?
J’ai un avis un peu différent : pour construire seul un MVP, je pense qu’il faut un outil capable de mettre en place, avec un minimum de code, trois éléments au moins : le schéma de base de données, le WAS et l’UI. Et je pense qu’il existe d’excellentes alternatives à PHP, à savoir Ruby on Rails et Django.
Dans le cas de Django, il suffit de définir les classes de modèle selon le pattern Active Record (un terme vraiment daté, n’est-ce pas) pour obtenir le schéma de base de données ainsi qu’une interface CRUD de back-office à peu près exploitable. Il fournit aussi les outils minimaux nécessaires au développement d’un service web : authentification, contrôle d’accès, validation des formulaires, outil de migration de base de données, outils de test, etc. Personnellement, depuis que j’ai commencé la programmation web à la fin des années 2000, je n’ai jamais retrouvé une productivité comparable à celle de Django. Depuis que l’approche SPA est devenue tendance et que les métiers frontend et backend se sont séparés, j’ai même l’impression que la productivité a diminué. Il faut en effet qu’au moins deux personnes comprennent le parcours utilisateur et travaillent avec un protocole aligné pour pouvoir avancer en parallèle.
Si PHP voulait se présenter comme un langage de template pour applications web, je pense qu’il aurait dû fournir, au niveau même du langage, des moyens de se prémunir contre les vulnérabilités web. Le fait que le style moderne de PHP ait adopté une approche de développement fondée sur les frameworks me semble en être la preuve.
Et depuis longtemps déjà, PHP ne se présente plus comme un langage de script à usage général.
Je ne comprends pas pourquoi vous comparez un langage et un framework.
Il y a Laravel, qui reprend les concepts de Ruby on Rails et de Django.
Je pense que lorsque le modern PHP ne sera plus vraiment « moderne » mais sera établi comme la méthode de développement standard de PHP, et que les CMS, y compris WordPress, auront adopté le modern PHP, alors PHP sera perçu par les gens comme un langage généraliste sûr. En règle générale, rétablir la confiance demande plus d’efforts que de la briser.
C’est parce qu’au nom du maintien de la rétrocompatibilité, on permet aux débutants de créer des services web peu sûrs avec les seules fonctionnalités de base de PHP. Parmi les 5 premiers sites trouvés en recherchant
PHP tutorial, aucun — à part le site officiel de PHP — n’indique qu’il faut appliquer un échappement HTML lorsqu’on affiche le contenu des superglobales pour se protéger contre les XSS. Puisqu’ils fournissent officiellement des guides qui couvrent le développement web, PHP ne joue-t-il pas à la fois le rôle de langage et de framework ?Que pensez-vous du fait que divers éléments de HTTP sont fournis nativement sous forme de noms de variables superglobales ? Pour ma part, je pense que l’étendue de la généralité et les cas d’usage sont déterminés par ce que le langage exprime.
Par exemple, les superglobales comme
$_GETet$_POSTque vous citez sont des valeurs exposées lorsque PHP est utilisé en mode CGI ou SAPI. Si PHP est utilisé en CLI, ces valeurs ne sont pas exposées.Ces superglobales sont une forme d’API exposée par des runtimes qui exécutent PHP, comme PHP-CGI ou PHP-FPM, et non une spécification du langage PHP en tant que tel.
De même, le « PHP qui se présente comme un langage de template » mentionné plus haut n’est pas, à proprement parler, PHP lui-même, mais plutôt CGI, l’un des runtimes de PHP, qui est conçu pour être utilisé de cette manière.
De la même façon, les nombreuses fonctions natives de PHP qui ont été qualifiées de vulnérabilités sont elles aussi des fonctions exposées par des extensions de PHP, et non des fonctionnalités du « langage » PHP lui-même.
Si l’on suit votre raisonnement,
JavaScript serait alors un langage et un framework conçus dès l’origine pour utiliser les API exposées par le navigateur afin de communiquer avec lui,
Java serait bien un langage, mais en pratique un framework utilisé pour exploiter les très nombreuses API du JDK,
et tous les autres langages devraient eux aussi être considérés comme des frameworks dès lors qu’ils fournissent une bibliothèque standard ou des API, indépendamment de la spécification du langage elle-même.
Bien sûr, la relation entre les deux est indissociable, mais s’appuyer sur cet aspect pour affirmer que PHP est un framework reste très peu convaincant.
Et même à ce jour, en mai 2024, quand on voit que des XSS sont encore corrigées dans le projet WordPress Core, il semble que des améliorations relevant uniquement de la syntaxe de PHP ne suffisent pas à empêcher les XSS.
Les frameworks frontend, les moteurs de templates côté serveur, etc., appliquent systématiquement l’échappement HTML à tout ce qui peut être rendu à partir de données, et ne produisent une sortie non sûre que lorsqu’on désactive explicitement cet échappement. PHP ne dispose pas d’une méthode consensuelle permettant d’appliquer ce traitement de manière globale. Si les instructions
echoouprintprenaient en charge l’échappement par défaut, cela aurait certes provoqué au départ une vague de code non fonctionnel, mais à long terme, cela aurait probablement permis à beaucoup de gens de réduire les erreurs d’omission d’échappement.Oui, je ne suis pas d’accord avec l’idée de séparer le langage et l’environnement d’exécution, et je pense que, d’une manière ou d’une autre, l’environnement d’exécution influence le langage. Dans le cas de JavaScript, il existe deux environnements d’exécution,
nodejset le navigateur, et pour Python, il existe de nombreuses implémentations, mais vous pouvez considérer quecpythonest dominante.Le sujet du billet original se limite aux améliorations syntaxiques, mais je voulais parler d’un périmètre un peu plus large que ce cadre.
> Je pense aussi que Laravel est quelque chose qui aurait dû être proposé comme fonctionnalité officielle du langage vers 2007, par des entreprises comme Rasmus ou Zend, plutôt qu’en 2011 par des contributeurs open source sous forme de projet distinct. L’adoption de Python 3 a été freinée parce qu’il a partiellement sacrifié la rétrocompatibilité, mais je pense aussi que PHP aurait dû faire un grand ménage de rétrocompatibilité vers la version 5. J’ai parfois l’impression que l’évolution de PHP est toujours un peu en décalage avec son époque.
Cela fait aussi office de réponse au commentaire ci-dessus.
Sous cet angle, je peux comprendre l’idée de considérer PHP comme une sorte de framework web.
Cela dit, je ne pense pas que PHP doive fournir par défaut diverses fonctionnalités comme le filtre XSS, l’échappement, etc.
Le très répandu PHP-FPM n’occupe pas la même position que Django ou RoR.
Il est plus proche de Flask, Sinatra ou Express.
PHP-FPM ne va pas au-delà du routage (basé sur les répertoires), de l’interprétation des requêtes (
$_GET,$_POST,$_FILE,$_COOKIE), de l’envoi des réponses (echo,print) et de la gestion des sessions ($_SESSION).Est-ce différent avec Flask ?
Dans Flask, pour renvoyer une réponse avec échappement HTML, un simple
returnne suffit pas.https://flask.palletsprojects.com/en/3.0.x/quickstart/#html-escaping
Est-ce différent avec Sinatra ?
Là aussi, il faut utiliser une bibliothèque d’échappement séparée.
https://sinatrarb.com/faq.html#escape_html
Est-ce différent avec Express ?
Même chose ici, il faut également utiliser une bibliothèque d’échappement distincte.
https://expressjs.com/en/resources/middleware.html
Aucune des bibliothèques citées en exemple n’est fournie officiellement par ces frameworks.
Alors pourquoi PHP devrait-il absolument proposer officiellement ce type de fonctionnalités ?
Si l’on affirme que PHP est nul pour des raisons déjà largement évoquées, du genre
"Quel framework complètement dingue expose les données de requête dans des variables superglobales ; même si ça ne pose pas de problème de sécurité, c’est un manque de respect envers l’utilisateur !",
je peux encore le comprendre, mais
j’ai du mal, au moins personnellement, à être d’accord avec l’argument selon lequel « les fonctionnalités de base de PHP ne sont pas aussi complètes que ce que fournit un framework full-stack ».
De la même manière que Nestjs a été créé pour utiliser Express de façon plus moderne et plus structurée, on peut considérer que Laravel a été créé pour utiliser PHP de façon plus moderne et plus structurée…
Dans ce cas, plutôt que de se focaliser sur des défauts comparatifs par rapport à d’autres frameworks (ou langages), est-ce qu’on ne ressent pas davantage, comme je l’avançais dans mon commentaire initial, les avantages propres à PHP(-FPM) ?
En y repensant, je pense qu’on aurait au moins pu réduire les erreurs PHP que nous avons faites sur le projet si la combinaison slim + twig s’était généralisée. Bien sûr, comme les autres développeurs PHP de l’époque étaient habitués à coder en PHP « brut », il n’était pas possible de l’introduire à ce moment-là. Heureusement, PDO faisait partie de la bibliothèque standard, ce qui nous permettait au moins de nous prémunir contre les injections SQL
Concernant la limitation de l’impact des bugs ou les performances de traitement mentionnées dans le commentaire d’origine, je n’ai pas vraiment d’avis tranché, ni pour ni contre. Je pense que ce sont des fonctionnalités utiles, mais comme les problèmes d’explosion du débit ou d’utilisation mémoire sont des sujets auxquels il faut réfléchir au moins une fois pendant la phase de croissance, je trouve préférable que ce type de problème apparaisse sous une forme explicite le plus tôt possible.
> Bien sûr, à l’époque, ce n’était pas possible de l’introduire, parce que les autres développeurs PHP étaient habitués à coder « à l’arrache » en PHP.
> Parce que faire évoluer les gens qui savent développer en PHP est ce qui prend le plus de temps et ce qui est le plus difficile.
Personnellement, je pense que PHP en lui-même n’a pas vraiment de problème, qu’il existe des moyens suffisants d’y répondre, ou qu’il ne s’agit au pire que de différences apparues pour des raisons compréhensibles, comme dans d’autres langages. Mais ce problème de ressources humaines dont vous parlez… au fond, je me demande si ce n’est pas ça, le plus gros problème.
Les développeurs capables d’utiliser PHP sérieusement ont déjà, depuis longtemps, été dégoûtés par le PHP d’autrefois et ont quitté l’écosystème PHP depuis belle lurette,
et la majorité de ceux qui restent sont des gens qui, peu importe les progrès de PHP, ne le considèrent pas correctement — ou n’ont tout simplement pas les moyens de le faire correctement…
Sur des projets de type MVP+a pour lesquels PHP me paraît adapté, il n’y a aucune raison pour que les profils expérimentés du premier groupe participent,
et même s’ils participaient, soit ils ne choisiraient pas PHP, soit, même en choisissant PHP, dès qu’une ou deux personnes du second groupe se joignent au projet, ça deviendrait vite un désastre… haha
Au moins en Corée, trouver des profils capables de faire du développement PHP à un niveau satisfaisant n’est déjà pas facile en soi.
Du coup, PHP est encore écarté des options, le niveau moyen des profils baisse encore davantage, et cela se répète à l’infini en créant un cercle vicieux.
~~Même si c’est en le vendant comme ça, au moins pour de petits projets de 1 à 3 personnes~~ je pense qu’il faut multiplier les cas où l’on essaie de mener de vrais projets PHP correctement pour pouvoir casser ce cercle vicieux.
Et moi aussi, au fond, les revenus que PHP me rapporte ne sont pas si importants. Comme il est trop difficile de recruter des profils satisfaisants, la réalité, c’est qu’on ne peut pas vraiment faire de PHP sa stack principale, même si on le voulait...
C’est lié à la différence de manière de produire des pages HTML entre les langages généralistes et PHP. Flask, au moins depuis la sortie de la version 1.0, a encouragé les gens à utiliser un moteur de templates et a été conçu pour en dépendre. Il a volontairement séparé les pages HTML des données côté serveur et a pris en charge un travail à l’échelle du template. Je pense que cela tient compte des caractéristiques du problème à résoudre et des habitudes d’utilisation des gens.
À l’inverse, avec PHP, la sortie standard devient directement une partie de la page, et la frontière entre les données côté serveur et la page HTML est floue. Ce qui est
printé se retrouve tel quel dans la page générée, et l’échappement doit être effectué explicitement par le développeur. Une conception qui impose d’ajouter la fonctionhtmlcharacterescapesà toutes les données externes n’a pas été bien acceptée. Les gens voulaient inconsciemment un système de templates, mais PHP semble ne pas avoir pris en compte l’objectif de l’utilisateur, qui est de produire des pages HTML.Si cette fonctionnalité doit faire partie de la bibliothèque standard, voire du langage lui-même, c’est parce que c’est la méthode la plus efficace quand on tient compte de la configuration de l’environnement PHP et de la manière dont le code est déployé. L’environnement de développement est standardisé autour de la stack LAMP, l’environnement d’exploitation autour de l’hébergement web, et comme les gens sont habitués à déployer en envoyant des fichiers via FTP, la possibilité de fournir des packages additionnels est plus faible que pour un langage généraliste. On ne peut pas non plus demander à des débutants d’installer des modules. Il ne reste donc comme options que la bibliothèque standard et la documentation standard.
> Les gens voulaient inconsciemment des templates, mais PHP ne semble pas avoir été pensé en tenant compte de l’objectif de l’utilisateur, à savoir générer des pages HTML.
Je ne trouve pas cela particulièrement convaincant.
À l’époque de PHP3, qui se contentait essentiellement d’exposer facilement une API C via CGI, on peut effectivement dire qu’il était utilisé comme système de templates, comme vous l’avez indiqué…
Mais à partir de PHP 4.2, l’environnement était déjà devenu suffisamment mûr pour des usages généralistes.
On disposait d’un environnement où l’on pouvait s’attendre à ce que le code soit exécuté via la CLI, et comme vous l’avez mentionné dans votre commentaire précédent, l’idée que « Laravel aurait dû apparaître vers 2007 non pas comme projet indépendant mais comme fonctionnalité officielle du langage » ne correspond absolument pas à l’orientation que prenait PHP à l’époque.
L’existence de Smarty, moteur de templates pour PHP publié en 2004, ou de CodeIgniter, framework MVC pour PHP publié en 2006, montre bien que PHP lui-même n’était pas un langage de templates, et l’on peut aussi en déduire qu’un consensus social s’était déjà formé dans l’écosystème PHP pour ne pas l’utiliser ainsi.
> Les frameworks frontend, les moteurs de templates côté serveur, etc., appliquent systématiquement un échappement HTML à tout ce qui peut être rendu à partir de données, et ne produisent une sortie non sûre que lorsqu’on désactive explicitement cet échappement.
Là encore, je ne pense pas que ce soit vraiment exact si on compare cela à la chronologie de PHP.
À partir de la première publication de Django en 2005, et pendant encore plusieurs années ensuite, l’échappement HTML n’était pas la configuration par défaut. Le développeur devait volontairement configurer un filtre d’échappement. Même aujourd’hui, dans le cas de Jinja, toujours utilisé en Python, l’échappement HTML n’est pas encore appliqué automatiquement.
À l’époque où l’échappement automatique est devenu la norme, PHP avait depuis longtemps abandonné son identité de langage de templates. (Les utilisateurs qui employaient alors PHP sans trop réfléchir ne le souhaitaient sans doute pas, mais on peut aussi voir les choses autrement : PHP avait déjà décidé d’écarter progressivement ce type d’utilisateurs.)
Puisque PHP n’est plus un langage destiné à cet usage, il n’y a aucune raison d’appliquer par défaut ce type de fonctionnalité dans la bibliothèque standard ou dans le langage lui-même ; du point de vue de PHP, qui veut fonctionner comme langage généraliste, la fonction
htmlcharacterescapesremplissait déjà suffisamment son rôle.> Comme l’environnement d’exploitation est standardisé autour de l’hébergement web et qu’on est habitué à simplement envoyer des fichiers par FTP, la possibilité de fournir des paquets additionnels est plus limitée que dans un langage généraliste.
Là non plus, j’ai du mal à être vraiment d’accord. Depuis bien plus d’une dizaine d’années, on utilisait déjà très bien git et d’autres outils du même genre. On a même très largement tenté des déploiements avec Docker dès sa sortie, et c’est encore le cas aujourd’hui.
J’ai l’impression que la plupart des points que vous mentionnez ont moins à voir avec PHP qu’avec les situations où l’on bricole sur des CMS développés en PHP.
Je n’aime pas trop ce genre d’expression, mais ce sont aussi ces cas où même les développeurs PHP ne vous considèrent pas vraiment comme développeur…
La fonction d’échappement automatique de jinja prouve que mon affirmation était erronée, et que ce que vous avez mentionné est exact.
> J’ai aussi du mal à être vraiment d’accord avec ce qui précède. Depuis bien plus d’une dizaine d’années, nous utilisions déjà très bien git et d’autres outils du même genre. Nous avons même largement tenté des déploiements avec Docker dès juste après sa publication, et nous l’utilisons toujours ainsi aujourd’hui.
Mon expérience de PHP s’est arrêtée en 2014, et à l’époque il n’y avait pas Docker. Nous ne pouvions pas non plus introduire git, car cela aurait nécessité de changer notre manière de travailler. En pratique, quand il faut introduire ce genre de choses dans un environnement de travail réel, il faut qu’il y ait un consensus, et dans ma situation c’était impossible.
> Je n’aime pas ce genre d’expression, mais ce sont aussi ces cas où l’on ne considère même pas les développeurs PHP comme de vrais développeurs...
Avec le recul, j’imagine que je travaillais parmi des gens qui n’étaient eux-mêmes pas considérés comme de vrais développeurs.
Les éléments que vous avez cités pour Django — authentification, contrôle d’accès, validation des formulaires, outils de migration de base de données et outils de test — sont tous également proposés par Laravel en PHP.
Authentification : https://laravel.com/docs/11.x/authentication
Contrôle d’accès : https://laravel.com/docs/11.x/authorization
Validation des formulaires : https://laravel.com/docs/11.x/validation
Migrations DB : https://laravel.com/docs/11.x/migrations
Tests : https://laravel.com/docs/11.x/testing
Il existe aussi, via des bibliothèques externes ou payantes,
des outils capables d’exporter un schéma de base de données existant en modèles et en code de migration, ou de faire l’inverse,
et il existe également https://nova.laravel.com/ qui fournit un back-office propre avec une interface CRUD.
Presque toutes les fonctionnalités de Django existent aussi dans Laravel.
(À la base, comme les deux reprennent le concept de RoR, il est inévitable que les fonctionnalités proposées soient similaires.)
Malgré cela, contrairement au duo Django-Python, Laravel-PHP bénéficie en plus des avantages que j’ai mentionnés dans mon commentaire d’origine.
On ne peut pas nier que PHP a été conçu à l’origine comme un langage de templates pour applications web,
mais à ce stade, alors que le style PHP moderne est installé depuis presque dix ans, je trouve un peu sévère de continuer à le voir uniquement comme un simple langage de templates.
J’ai regardé Nova parce qu’il avait été mentionné, mais c’est aussi une licence payante. Même si les fonctionnalités peuvent ressembler à celles de l’admin Django, clairement indiqué dans les tutoriels du projet et utilisable immédiatement, il semble y avoir une différence en termes d’accessibilité.
Par ailleurs, je pense que Laravel est quelque chose qui aurait dû apparaître non pas grâce à des contributeurs open source, mais comme fonctionnalité officielle du langage, sous l’impulsion de Rasmus ou d’entreprises comme Zend, vers 2007 plutôt qu’en 2011, et non comme projet indépendant. L’adoption de Python 3 a certes été freinée parce qu’il a partiellement renoncé à la rétrocompatibilité, mais je pense aussi que PHP aurait dû faire un grand ménage de rétrocompatibilité vers la version 5. J’ai aussi l’impression que les évolutions de PHP ont toujours un temps de retard sur l’évolution de l’époque.
À titre personnel, comme je ne suis plus dans une phase de découverte du développement web, je ne choisirai probablement plus PHP.
Vous confondez sans cesse le langage et le framework.
Je pense qu’il n’est pas nécessaire de publier le même commentaire à plusieurs endroits. Cherchez-vous à attirer l’attention ?
Bien sûr, c’est meilleur qu’avant, mais tant qu’à utiliser PHP aujourd’hui, j’ai l’impression que Node.js ou Python ont davantage d’usages polyvalents.
Le boom de PHP arrive.
Il n’y a aucune mention de l’amélioration de l’écosystème PHP, des méthodes de déploiement, du modèle d’exécution, des méthodes de débogage, etc., au cours des 10 dernières années. Comme ce qui prend le plus de temps et est le plus difficile, c’est de faire évoluer les personnes qui savent développer en PHP, je n’ai pas vraiment d’espoir que cela s’améliore. En particulier, l’article lié étant un blog marketing d’un freelance PHP, il faudrait le prendre avec d’autant plus de recul.
Au cours des dix dernières années, si l’on se base sur les statistiques d’usage de PHP via les paquets Composer (une distribution comparable à npm pour Node), les versions antérieures à PHP 5 ont pratiquement disparu, et l’écosystème PHP s’est depuis longtemps recentré sur Composer.
Certains CMS comme WordPress, GnuBoard, etc. sont complètement à part.
En dehors des CMS, l’écosystème est dans la situation décrite ci-dessus.
Du point de vue de quelqu'un qui utilise PHP, PHP reste malgré tout le pire langage.
C'est juste que les autres langages se sont améliorés.
Commentaires Hacker News
Résumé :
fopen()PHP : une fractale de mauvais design (en coréen)
Un document vieux de 12 ans lol
Un document écrit en 2012, encore aujourd'hui....
Vous pensez vraiment que PHP serait resté figé à cette époque de 2012, sans aucun progrès..?
Bon, après, on ne peut pas vraiment nier que c'est un langage qui a démarré sans véritables fondations. hehe
Voici le lien vers la traduction du document anglais mentionné..
Même si PHP avait beau être vraiment médiocre, il ne maintient sûrement pas encore les problèmes de cette époque-là.
Même quand on le maintient, c’est problématique. À ce niveau, la conception est déjà mauvaise dès le départ, alors dire que la qualité s’est améliorée avec les montées de version ? C’est justement le problème, parce que cela casse gravement la compatibilité descendante. Même les opérateurs de comparaison sont bizarres, alors qu’est-ce qu’on peut y faire ?
Il semble qu’il s’agisse simplement de la traduction coréenne du 4e lien du résumé de Hacker News, haha.