Vous aimez ce format ? Qu'en pensez-vous ? Le PHP a une histoire très incroyable, rempli de failles, d'amélioration, de fails et de réussite. Il est fort critiqué mais reste très utilisé. Mais si tu gères bien ton code en tant que développeur, hormis les failles de sécurité que tu pourrais rencontrer, tu peux réaliser de très belles choses ! (Ex : WordPress)
PHP est une masterclass. Non, sérieusement comme tous langages, PHP a ses avantages et défauts et ceux qui le critiquent ne l'utilisent pas de la bonne manière. Tu as tout à fait raison sur cette mauvaise réputation mais il ne doit pas remettre en cause son utilisation. J'utilise Laravel et c'est très plaisant. Force à toi, la vidéo était sympa
Contrairement à ce que tu penses, je connais PHP et l'utilise. Cet avis est changeable en fonction des développeurs, regarde les commentaires et lis par toi-même 😉 C'est un débat ouvert pas une décision à prendre de "si ce contenu te plaît ou pas". Néanmoins merci pour ton commentaire 🙏🏻✨
Perso je me pose pas la question. Je dév en PHP et JavaScript, ça rend service à mes clients et ça rempli le frigo. Point. Quand j'ai un doute sur un projet conséquent je missionne un pentester, je corrige et basta. Elle est simple la vie 🙂
Comme tout outil, un marteau, un couteau... c'est souvent l'utilisateur à remettre en cause ! Entre un code spaghettis et un petit mvc/poo bien ordonné, ça reste du php, mais c'est quand même pas pareil 😅 Et comme dit dans les précédent commentaires, php est souvent critiqué par : - ceux qui ne l'utilisent pas - ceux qui ont arrêté à php 5 et cherchent encore la V6 Et puis, ça reste un outil à utiliser au besoin, pas à tout bout de champs !!! Merci pour ta vidéo , sympa 😉
Franchement j'ai débuter la prog avec PHP langage type top pour débuter il y avait l'asp en concurrence mais php était plus simple d'apprentissage Longue vie a PHP
je crois surtout que python dans l'indice tiobe est en train de tout ravagé. J'utilise aussi des morceaux d'autres langages néanmoins. Y a pas de bon ou de mauvais langage mais php est pour moi inutile. L'écosystème de python contre php c'est comme l'amazonie versus les forêts françaises. Tout dépend aussi de votre niveau et accumulation de projets mais sur du long terme.
@@prenomnom4561 Le python ne vit pas en Amazonie, il n'y a que des anacondas là-bas. Il n'y a pas d'éléphant dans les forêts françaises (°), encore moins d'éléphant bleu ardoise. (°) _à Thoiry c'est le zoo qui est dans la forêt, pas les éléphants qui eux sont dans le zoo_
Je connais PHP mais probablement pas cette version, effectivement. Cette vidéo est un débat ouvert envers PHP. Basé sur des heures de recherche et sur mon expérience personnelle. Néanmoins merci pour ce commentaire constructif et cet avis sur PHP
Je développe avec php depuis sa version 4, chaque année une nouvelle vague de marketing pour le mettre a terre mais il garde toujours sa première place. Si il y’a un scripting 100% web ça sera le php point. Facile, dynamique souple et accepté chez toutes les plateformes d’hébergement.
Moi je suis passé de php(appris à l'université) à JavaScript. Tres franchement je ne me lasse pas de troller les devs php. Mais ce qui est sûr cest que chaque langage à ses avantages et inconvénients. Au final quand in maîtrise sa stack, on peut construire tout rt n'importe quoi
PHP est mal vu car les gens ne réfléchissent pas. PHP8 est très performant, très puissant, et on a affaire des devs front ends qui pensent qu'ils sont aussi des devs backend avec du JS, qui est un langage de merde avec une librairie standard ultra pauvre où chaque projet node a besoin de milliers de modules mal codés, et des devs qui font du mauvais boulot, car ce sont de mauvais devs backend.
Tu as craché toute ta haine 🤣🤣 , mais tu as raison. Entant que dev react & Laravel. Je travaille au quotidien avec du JS et du PHP. Et je confirme qu'à mes débuts ne connaissant que le j.s je crachait beaucoup sur le p.h.p avant de découvrir sa puissance
@@the_protakuMoi aussi , mais il faut rectifier aussi , Js est un très bon langage et riche 😅. Sinon ceux qui critiquent PHP c'est la plupart du temps les devs Js et ils le critiquent parce qu'ils ont commencé le backend en Js directement avec un framework hors PHP est typiquement backend ce qui veux dire qu'il est aussi beaucoup utilisé sans framework et qui dit sans framework dit que le dev lui même doit faire son architecture
@@Bamori-zy4ku la lib standard de JS est très pauvre. C'est pas un problème en soit, ça le devient quand on demande d'en faire un language four tout. Ya une raison pour laquelle toutes les web apps, et même des apps modernes comme slacks bouffent toute la RAM : c'est fait en JS. IRC ya 20 ans, et qui avait énormément de features, ça prenait quelques dizaines de Mo au démarrage. Slack me prend 500-600 quand je le lance, c'est du délire. Beaucoup de devs reviennent en arrière, c'est pour ça que des libs comme HTMX ont le vent en poupe, on fait du JS simple, avec un vrai language backend.
Bordel Dreamweaver tu viens de me mettre un sacré coup de nostalgie et de vieux par la même occasion 🤣J'avais même commencé avec Frontpage, en faisant des templates avec Photoshop et en découpant avec les tranches de calque 😅
"La seule raison"... Je ne pense pas . Si tel était le cas alors serait en chute libre aujourd'hui, or c'est le contraire, il est de plus en plus utilisé
@@megasticky8968 Les framework node qui sont des usines à gaz n'ont pas du tout le vent en poupe, tout le monde se rend compte que le web moderne c'est horrible, et veulent revenir vers des choses plus simples.
Non c’était surtout il y a 10 ou 15ans, à l’époque de php 4/5 ou il y avait beaucoup d’exploit pour bypasser open_basedir (ce qui pouvait être très problématique sur des serveurs mutualisés) ou disable_functions par exemple.
@@guillaumeJonjon 1. Remote Code Execution (RCE) 2. Injection SQL 3. Inclusion de fichiers locaux et distants (LFI/RFI) 4. Cross-Site Scripting (XSS) 5. Cross-Site Request Forgery (CSRF) 6. Désérialisation non sécurisée 7. Attaque par force brute de session 8. Exécution de code arbitraire (via eval, exec, shell_exec, etc.) 9. Téléchargement de fichiers non sécurisé 10. HTTP Response Splitting 11. Fuite d'informations sensibles 12. Directory Traversal (ou Path Traversal) 13. Race Conditions (lorsqu'une ressource est accédée simultanément) 14. Rebinding DNS (dans les applications PHP dépendant de résolutions DNS) 15. Utilisation de fonctions cryptographiques obsolètes 16. Exploitation de Magic Methods (comme __wakeup, __destruct) 17. Clé de session prédictible 18. Injection LDAP 19. Injection XML (ou XML External Entity, XXE) 20. Header Injection (insertion de caractères non sécurisés dans les en-têtes) 21. Command Injection (quand une entrée utilisateur est directement passée dans des commandes système) 22. Clickjacking (via une absence d’en-têtes X-Frame-Options) 23. Session Fixation (permet d'usurper la session d'un utilisateur) 24. Cache Poisoning (contamination du cache du serveur ou navigateur) 25. Padding Oracle Attack (lorsque les données chiffrées sont manipulables) 26. CRIME/BEAST Attacks (vulnérabilités SSL/TLS affectant les sessions PHP) 27. Timing Attacks (déduire des informations sensibles via des variations de temps) 28. Side-Channel Attacks (attaques exploitant la mémoire ou la consommation énergétique) 29. Null Byte Injection (injecter un caractère nul dans une chaîne pour contourner des filtres) 30. Reflection Injection (utilisation des classes et fonctions dynamiques en PHP pour manipuler le code) 31. Server-Side Template Injection (utilisation des moteurs de templates pour injecter du code) 32. Subdomain Takeover (lorsque les sous-domaines PHP pointent vers des ressources non sécurisées) 33. Insecure Direct Object References (IDOR) (accès non autorisé aux objets en utilisant des identifiants prédictibles) 34. Insecure Randomness (faiblesse dans la génération de clés ou jetons aléatoires) 35. JSON Web Token (JWT) Malpractice (mauvaise implémentation ou stockage de JWT) 36. Weak Password Policy Exploits (facilité d’attaque brute-force sur les mots de passe) 37. Cross-Site Scripting via DOM (DOM-Based XSS) 38. Vulnérabilités de Parsing JSON/XML (causées par des failles dans le décodeur ou la librairie) 39. Server-Side Request Forgery (SSRF) (forcer un serveur à effectuer des requêtes à des services non autorisés) 40. Typage faible (vulnérabilité liée aux vérifications de type automatiques en PHP) 41. Memory Leaks et Buffer Overflow (peut conduire à des attaques de déni de service ou d’exécution de code)
@guillaumeJonjon 1. Remote Code Execution (RCE) : Permet à un attaquant d'exécuter du code arbitraire sur le serveur, souvent via des fonctions comme eval, assert, ou des inclusions de fichiers non sécurisées. Cette vulnérabilité est particulièrement dangereuse car elle donne un contrôle direct sur le serveur. 2. Désérialisation non sécurisée : En manipulant des données sérialisées, un attaquant peut injecter des objets ou modifier des données, entraînant des exécutions de code ou des fuites de données. Les méthodes magiques (__wakeup, __destruct) sont souvent ciblées dans ces attaques. 3. Server-Side Request Forgery (SSRF) : Permet de détourner un serveur pour envoyer des requêtes à des services internes ou externes. En PHP, cette vulnérabilité peut survenir via des fonctions comme file_get_contents, curl_exec, et est exploitée pour accéder à des services internes ou récupérer des informations sensibles. 4. Injection XML (XXE - XML External Entity) : Exploite les entités XML pour injecter des fichiers locaux ou accéder à des ressources internes du serveur. Cette vulnérabilité peut conduire à des fuites de données sensibles, surtout dans des bibliothèques de parsing XML. 5. Insecure Deserialization via Phar (PHP Archive) : En utilisant les archives Phar, un attaquant peut insérer du code malveillant dans un fichier PHP. Lorsqu'un script tente d'ouvrir un fichier Phar pour la désérialisation, le code est exécuté. Cette attaque peut contourner les filtres de désérialisation sécurisés dans certaines configurations.
Trop permissif, on peut faire n'importe quoi et ça devient inévitablement impossible à maintenir (à moins de n'avoir QUE des bons dev mais c'est impossible dans les projets importants, et puis les bon dev ne codent pas en PHP 🤣). Je préfère largement Python.
Vous aimez ce format ? Qu'en pensez-vous ?
Le PHP a une histoire très incroyable, rempli de failles, d'amélioration, de fails et de réussite. Il est fort critiqué mais reste très utilisé.
Mais si tu gères bien ton code en tant que développeur, hormis les failles de sécurité que tu pourrais rencontrer, tu peux réaliser de très belles choses ! (Ex : WordPress)
PHP est une masterclass. Non, sérieusement comme tous langages, PHP a ses avantages et défauts et ceux qui le critiquent ne l'utilisent pas de la bonne manière. Tu as tout à fait raison sur cette mauvaise réputation mais il ne doit pas remettre en cause son utilisation. J'utilise Laravel et c'est très plaisant. Force à toi, la vidéo était sympa
🙏🏻✨
Moi aussi j'utilise Laravel et je suis satisfait de PHP. Le créateur de ce contenu, ça se voit que lui aussi ne connait pas PHP
Contrairement à ce que tu penses, je connais PHP et l'utilise. Cet avis est changeable en fonction des développeurs, regarde les commentaires et lis par toi-même 😉 C'est un débat ouvert pas une décision à prendre de "si ce contenu te plaît ou pas". Néanmoins merci pour ton commentaire 🙏🏻✨
Php reste mon langage préféré pour côté back end
Perso je me pose pas la question. Je dév en PHP et JavaScript, ça rend service à mes clients et ça rempli le frigo. Point. Quand j'ai un doute sur un projet conséquent je missionne un pentester, je corrige et basta. Elle est simple la vie 🙂
Comme tout outil, un marteau, un couteau... c'est souvent l'utilisateur à remettre en cause !
Entre un code spaghettis et un petit mvc/poo bien ordonné, ça reste du php, mais c'est quand même pas pareil 😅
Et comme dit dans les précédent commentaires, php est souvent critiqué par :
- ceux qui ne l'utilisent pas
- ceux qui ont arrêté à php 5 et cherchent encore la V6
Et puis, ça reste un outil à utiliser au besoin, pas à tout bout de champs !!!
Merci pour ta vidéo , sympa 😉
Salut, sympa la video et content d'apprendre à travers les commentaires que php est tjrs là et bien là ^^
Bonne chance pour la suite.
Salut, merci pour le soutien ! Oui exact on remercie les viewers pour leur présence !
2:18 phpmyadmin n'est pas un SGBD...
On me l'a déjà fait remarquer. Erreur de ma part, ce sera corrigé bg 👍🏻
Tous ceux qui parle mal de php sont arrêter à php 5. Sinon depuis php7 et 8 php est très puisant.
🙏🏻✨
faire un petit crud en php, c'est une des rares douceur qui vous donne envie de vous lever le matin
Franchement j'ai débuter la prog avec PHP langage type top pour débuter il y avait l'asp en concurrence mais php était plus simple d'apprentissage
Longue vie a PHP
🙏🏻✨
je crois surtout que python dans l'indice tiobe est en train de tout ravagé. J'utilise aussi des morceaux d'autres langages néanmoins. Y a pas de bon ou de mauvais langage mais php est pour moi inutile. L'écosystème de python contre php c'est comme l'amazonie versus les forêts françaises. Tout dépend aussi de votre niveau et accumulation de projets mais sur du long terme.
@@prenomnom4561 Le python ne vit pas en Amazonie, il n'y a que des anacondas là-bas. Il n'y a pas d'éléphant dans les forêts françaises (°), encore moins d'éléphant bleu ardoise.
(°) _à Thoiry c'est le zoo qui est dans la forêt, pas les éléphants qui eux sont dans le zoo_
@@lmz-dev et le boa version le python++ arrive bientôt
Passionnant, merci beaucoup 👍
Tu ne connais pas PHP et tu n'est un Devp backend. Depuis sa version 8, PHP a énormément évolué rien à voir avec les versions
Je connais PHP mais probablement pas cette version, effectivement. Cette vidéo est un débat ouvert envers PHP. Basé sur des heures de recherche et sur mon expérience personnelle. Néanmoins merci pour ce commentaire constructif et cet avis sur PHP
Trop bien ^^ je savais pas ce que faisais php8, je suis content que php s ameliore ^^
Salut, bon sujet, bon montage, continue.
Salut ! 🎉
Php n'a pas à rougir de la concurrence c'est un langage d'une facilité deconcertante
Bon courage frérot 🔥
Je développe avec php depuis sa version 4, chaque année une nouvelle vague de marketing pour le mettre a terre mais il garde toujours sa première place.
Si il y’a un scripting 100% web ça sera le php point.
Facile, dynamique souple et accepté chez toutes les plateformes d’hébergement.
Moi je suis passé de php(appris à l'université) à JavaScript. Tres franchement je ne me lasse pas de troller les devs php. Mais ce qui est sûr cest que chaque langage à ses avantages et inconvénients. Au final quand in maîtrise sa stack, on peut construire tout rt n'importe quoi
Bonne video bonne continuation !
Top vidéo! Mais PhpMyAdmin n'est pas un SGBD c'est juste une interface web pour executer MySQL qui lui est un SGBD
Oui, ça m'a été précisé, mais merci pour ton commentaire ! 🙏🏻✨
Phpmyadmin n'exécute pas MySQL, c'est une interface de gestion de base de données.
C'est les web designer qui font que JS est numero 1 perso j'aime pas beaucoup. Il y avait une certaine concurrence avec PERL au début .
Excellent travail!
COOL LA VIDEO
PHP est mal vu car les gens ne réfléchissent pas. PHP8 est très performant, très puissant, et on a affaire des devs front ends qui pensent qu'ils sont aussi des devs backend avec du JS, qui est un langage de merde avec une librairie standard ultra pauvre où chaque projet node a besoin de milliers de modules mal codés, et des devs qui font du mauvais boulot, car ce sont de mauvais devs backend.
Tu as craché toute ta haine 🤣🤣 , mais tu as raison.
Entant que dev react & Laravel.
Je travaille au quotidien avec du JS et du PHP.
Et je confirme qu'à mes débuts ne connaissant que le j.s je crachait beaucoup sur le p.h.p avant de découvrir sa puissance
@@the_protakuMoi aussi , mais il faut rectifier aussi , Js est un très bon langage et riche 😅. Sinon ceux qui critiquent PHP c'est la plupart du temps les devs Js et ils le critiquent parce qu'ils ont commencé le backend en Js directement avec un framework hors PHP est typiquement backend ce qui veux dire qu'il est aussi beaucoup utilisé sans framework et qui dit sans framework dit que le dev lui même doit faire son architecture
T'en avais a dire toi 🤣🤣🤣
@@Bamori-zy4ku la lib standard de JS est très pauvre. C'est pas un problème en soit, ça le devient quand on demande d'en faire un language four tout. Ya une raison pour laquelle toutes les web apps, et même des apps modernes comme slacks bouffent toute la RAM : c'est fait en JS. IRC ya 20 ans, et qui avait énormément de features, ça prenait quelques dizaines de Mo au démarrage. Slack me prend 500-600 quand je le lance, c'est du délire.
Beaucoup de devs reviennent en arrière, c'est pour ça que des libs comme HTMX ont le vent en poupe, on fait du JS simple, avec un vrai language backend.
@@Bamori-zy4ku oui tu as 100% raison
Moi j'ai toujours détesté ce langage que je trouve pas du tout compatible avec ma façon de travailler. Chez moi c'est du python et du C++.
Petite precision PMA n'est pas un sgbd, même si je ne sais pas comment le nommer, par contre, il interagit avec des sgbd
C'est une interface de gestion de la base de données.
PhpMyAdmin n’est pas un SGBD, MySQL, MariaDB, oui. PMA sert juste d’interface
Dans les année 90, le métier de développeur commençait à se déployer 🤣🤣🤣
qu'est ce qu'on a fait pour avoir le droit à des âneries pareils ?? 🤣🤣🤣🤣🤣
Et si tu remplaçais ça par un avis plus constructif ? Serait-ce pas plus optimal pour éviter ce genre "d'âneries" ? 🤓
les néophytes qui découvrent les IA, nous on connaissait déjà avec dreamweaver, symfony, etc
Oui oui les à côtés du type symfony sont très connus, j'ai aussi utilisé Symfony pdt longtemps
Bordel Dreamweaver tu viens de me mettre un sacré coup de nostalgie et de vieux par la même occasion 🤣J'avais même commencé avec Frontpage, en faisant des templates avec Photoshop et en découpant avec les tranches de calque 😅
Php is my best language
Juste pour t'encourager . Php my admin n'est pas un SGBD merci pour la modification .
Merci pour ton commentaire, autant pour moi, j'en prends note.
La seule raison pour laquelle php est encore utilisée et continuera d’être utilisé (mais de moins en moins) est l’existence de projets legacies
"La seule raison"... Je ne pense pas . Si tel était le cas alors serait en chute libre aujourd'hui, or c'est le contraire, il est de plus en plus utilisé
@@fredchess de plus en plus ? Je crois que les frameworks js et python ont plus le vent en poupe en ce moment. Après j’ai peut être UN PEU exagéré
@@megasticky8968 Les framework node qui sont des usines à gaz n'ont pas du tout le vent en poupe, tout le monde se rend compte que le web moderne c'est horrible, et veulent revenir vers des choses plus simples.
Ducoup, il y a toujours ces problèmes de sécurité ?
Non c’était surtout il y a 10 ou 15ans, à l’époque de php 4/5 ou il y avait beaucoup d’exploit pour bypasser open_basedir (ce qui pouvait être très problématique sur des serveurs mutualisés) ou disable_functions par exemple.
Oui, il y a toujours énormément de vulnérabilités
@@T1_Shark1 tu as un exemple ?
@@guillaumeJonjon 1. Remote Code Execution (RCE)
2. Injection SQL
3. Inclusion de fichiers locaux et distants (LFI/RFI)
4. Cross-Site Scripting (XSS)
5. Cross-Site Request Forgery (CSRF)
6. Désérialisation non sécurisée
7. Attaque par force brute de session
8. Exécution de code arbitraire (via eval, exec, shell_exec, etc.)
9. Téléchargement de fichiers non sécurisé
10. HTTP Response Splitting
11. Fuite d'informations sensibles
12. Directory Traversal (ou Path Traversal)
13. Race Conditions (lorsqu'une ressource est accédée simultanément)
14. Rebinding DNS (dans les applications PHP dépendant de résolutions DNS)
15. Utilisation de fonctions cryptographiques obsolètes
16. Exploitation de Magic Methods (comme __wakeup, __destruct)
17. Clé de session prédictible
18. Injection LDAP
19. Injection XML (ou XML External Entity, XXE)
20. Header Injection (insertion de caractères non sécurisés dans les en-têtes)
21. Command Injection (quand une entrée utilisateur est directement passée dans des commandes système)
22. Clickjacking (via une absence d’en-têtes X-Frame-Options)
23. Session Fixation (permet d'usurper la session d'un utilisateur)
24. Cache Poisoning (contamination du cache du serveur ou navigateur)
25. Padding Oracle Attack (lorsque les données chiffrées sont manipulables)
26. CRIME/BEAST Attacks (vulnérabilités SSL/TLS affectant les sessions PHP)
27. Timing Attacks (déduire des informations sensibles via des variations de temps)
28. Side-Channel Attacks (attaques exploitant la mémoire ou la consommation énergétique)
29. Null Byte Injection (injecter un caractère nul dans une chaîne pour contourner des filtres)
30. Reflection Injection (utilisation des classes et fonctions dynamiques en PHP pour manipuler le code)
31. Server-Side Template Injection (utilisation des moteurs de templates pour injecter du code)
32. Subdomain Takeover (lorsque les sous-domaines PHP pointent vers des ressources non sécurisées)
33. Insecure Direct Object References (IDOR) (accès non autorisé aux objets en utilisant des identifiants prédictibles)
34. Insecure Randomness (faiblesse dans la génération de clés ou jetons aléatoires)
35. JSON Web Token (JWT) Malpractice (mauvaise implémentation ou stockage de JWT)
36. Weak Password Policy Exploits (facilité d’attaque brute-force sur les mots de passe)
37. Cross-Site Scripting via DOM (DOM-Based XSS)
38. Vulnérabilités de Parsing JSON/XML (causées par des failles dans le décodeur ou la librairie)
39. Server-Side Request Forgery (SSRF) (forcer un serveur à effectuer des requêtes à des services non autorisés)
40. Typage faible (vulnérabilité liée aux vérifications de type automatiques en PHP)
41. Memory Leaks et Buffer Overflow (peut conduire à des attaques de déni de service ou d’exécution de code)
@guillaumeJonjon
1. Remote Code Execution (RCE) : Permet à un attaquant d'exécuter du code arbitraire sur le serveur, souvent via des fonctions comme eval, assert, ou des inclusions de fichiers non sécurisées. Cette vulnérabilité est particulièrement dangereuse car elle donne un contrôle direct sur le serveur.
2. Désérialisation non sécurisée : En manipulant des données sérialisées, un attaquant peut injecter des objets ou modifier des données, entraînant des exécutions de code ou des fuites de données. Les méthodes magiques (__wakeup, __destruct) sont souvent ciblées dans ces attaques.
3. Server-Side Request Forgery (SSRF) : Permet de détourner un serveur pour envoyer des requêtes à des services internes ou externes. En PHP, cette vulnérabilité peut survenir via des fonctions comme file_get_contents, curl_exec, et est exploitée pour accéder à des services internes ou récupérer des informations sensibles.
4. Injection XML (XXE - XML External Entity) : Exploite les entités XML pour injecter des fichiers locaux ou accéder à des ressources internes du serveur. Cette vulnérabilité peut conduire à des fuites de données sensibles, surtout dans des bibliothèques de parsing XML.
5. Insecure Deserialization via Phar (PHP Archive) : En utilisant les archives Phar, un attaquant peut insérer du code malveillant dans un fichier PHP. Lorsqu'un script tente d'ouvrir un fichier Phar pour la désérialisation, le code est exécuté. Cette attaque peut contourner les filtres de désérialisation sécurisés dans certaines configurations.
Hummm bcp d'inexactitudes :-(
Tout n'est jamais parfait 👍🏻
c'est lent, ça change à chaque serveur, mais c'est le langage le plus accessible car pas besoin de dédié
C'est lent mais plus rapide que du nodejs
Php fait encore la résistance parce que plusieurs CMS sont conçus avec lui...
Intéressant et je dirais tant mieux ^^
Et c'est pas par hasard, c'est ce qu'il faut retenir !
Trop permissif, on peut faire n'importe quoi et ça devient inévitablement impossible à maintenir (à moins de n'avoir QUE des bons dev mais c'est impossible dans les projets importants, et puis les bon dev ne codent pas en PHP 🤣). Je préfère largement Python.
Je développe en java spring , si tu es.un bon dev ..tu es un bon dev partout.
Donc oui il y a plein de bon dev qui code en PHP.
bien sûr qu'il y a des bons devs qui codent en PHP, ohhhh.... 😊
La framework laravel est très puissante et simple à utilisé
J'ai énormément développé avec PHP et Python et je pense exactement l'inverse. Au niveau de la POO, python c'est la cata
Symfony est ultra robuste, il n y a pas du tout d'équivalent en python