Discussion :

[Vahia]

Bonjour à tous, je viens vers vous pour avoir votre avis.

Ma vision des choses est la suivante (exemple basé sur un site qui serait hébergé chez un hébergeur du type ionos) :
PHP a l'énorme avantage de rester côté serveur. Ainsi l'utilisateur ne voit jamais le code contrairement au javascript où, en cherchant un peu, il est facile de trouver le fichier JS et de consulter le code (et encore ça c'est dans le cas où le script n'est pas mis directement dans la page html auquel cas c'est encore plus simple à trouver). Ceci est très utile notamment lorsque l'on veut communiquer avec une base de données. On peut se logger directement depuis le code PHP de la page.
Si on veut faire la même chose en JS c'est impossible car sinon les identifiants de connexion à la BDD seraient facilement récupérables par un utilisateur mal intentionné. Du coup il faut héberger la BDD sur un serveur à part et faire communiquer site et BDD via une API. Mais de suite ça entraîne un coût supplémentaire pour le serveur hébergeant la BDD et de potentielles complications bien pénibles (CORS pour ne citer que ça).

Ma vision est bonne ou je me trompe quelques part ?
Parce que si ma vision est bonne, je ne comprends pas pourquoi on dit que le PHP est en perte de vitesse alors qu'il est bien plus pratique à utiliser que le JS...

[ze0ne]

Bonjour Vahia.
Effectivement, si tu veux exploiter une base de données... le plus souvent en javascript, tu vas avoir recourt à une API.
Elle peut être en php, java ou nodejs (javascript) et dans ce cas tu vas être confronté à des problématiques de sécurités, dont les soucis de CORS.

Dans tous les cas, il est de plus en plus courant de décorréler le back et le front, pour plusieurs raisons, notamment la capacité à mettre à jour l'un sans risquer de créer des régressions ou perturber l'autre ou bien de mieux gérer la scalabilité de l'appli.

Il y a a même en nouvelle "tendance" qui consiste à avoir une API, un service BFF (Back For Front) ainsi qu'un application en javascript afin d'ajouter une couche de sécurité supplémentaire pour se prémunir d'une action malveillante côté client.

Dans le domaine de l'industrialisions du web, on est loin d'être dans la simplification en réalité, mais plus dans l'optimisation des ressources, que ce soit humaine ou matérielle ou encore dans la sécurisation de l'accès aux données.

[Vahia]

Franchement les problèmes de sécurité de type CORS, c'est vraiment rédhibitoire...
Autant c'est plaisant de développer un front dynamique en JS (avec ou sans framework) qui communique avec une API qu'on a créé avec amour côté back, autant c'est nettement moins frustrant de tout faire en PHP avec la certitude qu'on n'aura pas les CORS et autre qui vont venir nous pourrir la vie.

J'ai l'expérience d'un projet React que j'ai fait il y a quelques mois. J'ai fait aussi le côté back avec BDD gérée via Prisma. Pas moyen de balancer ça sur mon hébergement ionos (je ne sais même pas si c'est possible en fait). J'ai du prendre un VPS pour y mettre mon back et là ça a été le début de la galère avec les CORS, les histoires de certificats et autre... Au final le projet est bancal et j'ai tout laissé en plan.