Comparatif PHP/JS

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...

Bonjour. Oui, mais là vous avez fait un comparatif entre un langage côté front (JS) et un langage côté back (PHP). Sauf qu'il y a plein de langages côté back : Java, Python, Ruby, Go, C++, et j'en passe et des meilleurs. Et même le JavaScript peut fonctionner côté back, avec Node.js.

Par contre, c'est complètement fou que certains puissent soutenir que PHP est en perte de vitesse, il fait fonctionner la plupart des sites dans le monde et de toute façon il s'est mis à niveau, il est très rapide maintenant. Mais il est vrai que beaucoup de développeurs ne l'apprécient pas, moi le premier. Sa syntaxe était affreuse (on sent le poids de son héritage), ça c'est beaucoup amélioré avec les dernières version de PHP, mais le language a gardé sa réputation. Et puis comparé à d'autres langages, qu'est-ce-que c'est verbeux !
Modifié par Olivier C (03 Oct 2022 - 12:52)

Bonjour,

Vahia a écrit :
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).

Olivier C a écrit :
Oui, mais là vous avez fait un comparatif entre un langage côté front (JS) et un langage côté back (PHP). Sauf qu'il y a plein de langages côté back : Java, Python, Ruby, Go, C++, et j'en passe et des meilleurs. Et même le JavaScript peut fonctionner côté back, avec Node.js.

+1

Ce n'est pas une question de langage mais d'endroit où le code s'exécute. Ceci étant, Vahia, tu as tout à fait raison, il ne faut pas mettre des informations sensibles dans du code JS destiné à être exécuté par le navigateur des internautes.

Vahia a écrit :
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).

Je ne vois pas ce que ça changerait dans ton cas de mettre la base de données sur un autre serveur. Ce qui s'exécute sur ton serveur principal n'est pas forcément plus visible de l'extérieur que ce qui serait placé sur un serveur secondaire hébergeant une base de données (ça dépend des situations de toute façon). Ça ne veut pas dire que ça ne sert à rien de mettre les bases de données sur un autre serveur (y a des tas de bonnes raisons à ça, par exemple si on veut soulager le serveur principal ou quand on a des bases de données utilisées par plusieurs serveurs).

Vahia a écrit :
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...

On dit que php est en perte de vitesse parce qu'il a perdu pas mal de parts de marché. C'est juste un constat. Chaque langage a ses avantages et inconvénients. Et chaque outil permettant d'utiliser ces langages (en gros les interpréteurs de ces langages) est plus ou moins bien fini, et plus ou moins bien mis à jour.

On notera que pour le JS côté serveur, l'intérêt est de n'avoir qu'un seul langage à manipuler au lieu de deux, vu que côté navigateur, on n'a pas trop d'alternative au JS actuellement. On aura donc moins de formations à prévoir, moins d'occasions de se tromper dans les syntaxes, plus de possibilités d'utiliser des morceaux de code à la fois côté serveur et côté navigateur sans avoir besoin de les ré-écrire dans un autre langage, etc.

Personnellement je suis neutre. Et si ça se trouve, dans 20 ou 30 ans, on utilisera peut-être quelque chose de complètement différent.

Amicalement,

@Olivier C : je n'ai pas cherché à comparer un langage serveur avec un langage front. D'autant que JS fait les 2. J'ai plutôt cherché à comparer 2 solutions pour un même problème. Et ce que je constate c'est que, malgré le fait que JS soit plus sympa à utiliser selon moi, PHP est nettement plus efficace et pratique pour la gestion de BDD.

@parsimonhi :

a écrit :
il ne faut pas mettre des informations sensibles dans du code JS destiné à être exécuté par le navigateur des internautes.

c'est là pour moi le gros point faible de JS.

a écrit :
Je ne vois pas ce que ça changerait dans ton cas de mettre la base de données sur un autre serveur. Ce qui s'exécute sur ton serveur principal n'est pas forcément plus visible de l'extérieur que ce qui serait placé sur un serveur secondaire hébergeant une base de données

C'est peut-être une erreur de ma part. Il me semble que chez ionos, tu ne peux accéder à la base de données qui t'es fournie avec ton hébergement que via PHP. Je dis ça parce que j'avais voulu héberger une appli React avec BDD gérée avec Prisma et liée avec une API. J'ai jamais réussi à déployer mon projet sans prendre un VPS (et encore j'en ai chié avec les CORS).
Mais une fois de plus peut-être que je me trompe. Peut-être qu'il est possible de mettre le front et le back (API) sur le même hébergement mais à ce jour je ne sais pas comment faire.

Bonjour,

Vahia a écrit :
...c'est là pour moi le gros point faible de JS.

Décidément, on se demande si tu saisis. Ce n'est pas une question de JS, mais le fait que tu exécutes du code sur le navigateur. On pourrait très bien avoir un autre langage s'exécutant sur le navigateur et on aurait le même problème. Ça existe d'ailleurs ces autre langages, mais en pratique, ce n'est pas employé ou rarement.

EDIT: et d'ailleurs, pour interroger une base de données, on n'a pas forcément besoin de JS. Du HTML avec un formulaire suffit.

Vahia a écrit :
Il me semble que chez ionos, tu ne peux accéder à la base de données qui t'es fournie avec ton hébergement que via PHP. Je dis ça parce que j'avais voulu héberger une appli React avec BDD gérée avec Prisma et liée avec une API. J'ai jamais réussi à déployer mon projet sans prendre un VPS (et encore j'en ai chié avec les CORS).
Mais une fois de plus peut-être que je me trompe. Peut-être qu'il est possible de mettre le front et le back (API) sur le même hébergement mais à ce jour je ne sais pas comment faire.

Evidemment que c'est possible de tout mettre sur un seul serveur. Mais il se peut bien entendu qu'il y ait des limitations selon les solutions d'hébergement employées (mutualisé ou pas mutualisé ? SGBD géré par l'hébergeur ou pas ? etc.) Et c'est peut-être pour ça que tu as des difficultés. Il n'y a pas de recette générale, c'est au cas par cas.

Amicalement,
Modifié par parsimonhi (04 Oct 2022 - 10:37)

Perso quand je lis ça :

a écrit :
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.

Je suis d'accord avec Olivier, tu compares php en tant que code "serveur" et le javascript en tant que code "client"
Si tu fais du javascript coté serveur (node.js ou autre) les fichiers "serveurs" ne sont pas accessibles par le client et il n'y a pas de risque particulier de se faire voler les données de connexion à la BDD. Si c'était le cas, les applis basé sur node.js se feraient pirater h24 et la techno n'aurait pas décollé.

Bref, je pense que ta "vision" est globalement fausse
Il faut plutôt distinguer 2 choses :
- ce que je veux envoyer au client
- comment je génère ce que je vais envoyer au client

Globalement dans 99% des cas ce que je veux envoyer au client c'est assez limité au final :
- du html
- du css
- probablement un peu de javascript pour avoir 2-3 interactions dans la page (et du coup en effet dans cette partie la du javascript on ne met pas d'infos sensibles comme la connexion à la base de données)
- éventuellement un peu d'ajax pour avoir de une modification de la page sans rechargement de la page (communication "invisible" (pour le client) avec le serveur)

Par contre sur comment je génère ce que je vais envoyer au client (et probablement récupérer des infos du client), c'est globalement transparent pour l'utilisateur mais la j'ai réellement une quantité de possibilités :
- PHP
- Java
- Python
- Ruby
- C#
- Javascript (node.js)
- il doit y en avoir encore une tartine de langages serveurs que je ne connais pas
- et aussi toutes les solutions low-code / no-code que je n'ai pas du tout regardé non plus.

Ensuite si je stock les infos de l'utilisateur, il faut savoir comment :
- SQL
- No-SQL
- et divers formats de fichiers (csv/excel/xml/json/yml/...)

Globalement chacun des langages / mixtes de langages va avoir ces avantages et inconvénients.

De mon point de vue, actuellement un des plus gros avantage du PHP par rapport aux autres langages n'a aucun rapport avec le langage en lui même.... : il est plus ou moins "coincé" dans un genre de cercle "vertueux" :
Il est majoritaire sur le marché -> on trouve beaucoup d’hébergeurs à petit prix pour le combo PHP/MYSQL -> Beaucoup de gens qui veulent se faire un "petit site" peuvent se permettre de payer l'hebergement chez eux, il leur faut une solution pour ne pas avoir à coder -> ils utilisent un CMS qui tournent en majorité en PHP -> PHP reste majoritaire sur le marché

Mais je suis d'accord qu'au départ un des gros avantage du PHP, c'était d’être facilement intégrable au code HTML pour se faire un petit site sans avoir besoin d’être très technique (et que historiquement c'est certainement ça qui lui à permis de prendre des parts de marchés).


Et ensuite pour les problèmes de CORS, peut etre que je confonds ce que c'est mais je trouve un peu étrange.
Si c'est une seule appli, elle est censé être "propriétaire" de tous ce qu'elle envoie au client, pas de raison que le client voit que cela arrive de serveurs différents

a écrit :
Si tu fais du javascript coté serveur (node.js ou autre) les fichiers "serveurs" ne sont pas accessibles par le client et il n'y a pas de risque particulier de se faire voler les données de connexion à la BDD. Si c'était le cas, les applis basé sur node.js se feraient pirater h24 et la techno n'aurait pas décollé.

Je suis entièrement d'accord.

a écrit :
Et ensuite pour les problèmes de CORS, peut etre que je confonds ce que c'est mais je trouve un peu étrange.
Si c'est une seule appli, elle est censé être "propriétaire" de tous ce qu'elle envoie au client, pas de raison que le client voit que cela arrive de serveurs différents

Que je sache, un serveur node ne peut pas tourner depuis l'espace lié à l'hébergement (auquel on accède généralement via ftp). Il faut le placer dans un VPS qui n'a pas la même IP que ton site où est situé tout le front. Du coup le client prend ça pour une origine différente. D'où le problème de CORS.

Mathieuu a écrit :
De mon point de vue, actuellement un des plus gros avantage du PHP par rapport aux autres langages n'a aucun rapport avec le langage en lui même.... : il est plus ou moins "coincé" dans un genre de cercle "vertueux" :
Il est majoritaire sur le marché -> on trouve beaucoup d’hébergeurs à petit prix pour le combo PHP/MYSQL -> Beaucoup de gens qui veulent se faire un "petit site" peuvent se permettre de payer l'hebergement chez eux, il leur faut une solution pour ne pas avoir à coder -> ils utilisent un CMS qui tournent en majorité en PHP -> PHP reste majoritaire sur le marché

Mais je suis d'accord qu'au départ un des gros avantage du PHP, c'était d’être facilement intégrable au code HTML pour se faire un petit site sans avoir besoin d’être très technique (et que historiquement c'est certainement ça qui lui à permis de prendre des parts de marchés).

This. Rien à ajouter.

Sinon les autres l'ont bien expliqué. Faut pas confondre le langage et l'environnement dans lequel il est exécuté. Si tu fais une API avec NodeJS en JavaScript, tu ne divulgue pas ton code sensible au client.

Et enfin, on peut s'amuser à trouver des défauts à PHP aussi. Il est resté longtemps en retard par rapport à d'autres qui ont évolué plus rapidement. C'est pas un langage typé par nature, donc plus permissif, plus apte à contenir des erreurs et par conséquent moins robuste. Qu'en est-il des autres paradigmes comme la programmation fonctionnelle ou réactive ? Je crois pas que l'on soit si bien servis qu'avec du Java / Kotlin / JavaScript et j'en passe. Et que valent les gestionnaires de projets / dépendances ? Composer ne fait pas le poids face à Gradle, Maven ou même NPM simplement (puisqu'on comparait avec le JavaScript à la base).
Modifié par Anymah (04 Oct 2022 - 23:11)

Vahia a écrit :
Que je sache, un serveur node ne peut pas tourner depuis l'espace lié à l'hébergement (auquel on accède généralement via ftp). Il faut le placer dans un VPS qui n'a pas la même IP que ton site où est situé tout le front. Du coup le client prend ça pour une origine différente. D'où le problème de CORS.

Qu'est ce que tu appelles "l'espace lié à l’hébergement" ? J'ai l'impression que tu as plusieurs serveurs mais je ne comprends pas pourquoi
Je ne sais pas si il existe des serveurs mutualisés "dédiés pour faire du nodejs" comme on trouve pour php, je suppose que non et que c'est pour ça que tu as pris un VPS, mais du coup tu déposes toute ton appli sur le VPS et il distribue tout et ça roule.

Et si tu as plusieurs serveurs, tu dois pouvoir configurer pour que cela soit transparent (genre montage nfs ou autre)

Quand tu soucrits un contrat d'hébergement on te fourni un espace de stockage sur un serveur mutualisé sur lequel tu vas déposer tes pages web. C'est de cet espace dont je parle. Ce serveur gère nativement le PHP ce qui est très pratique. Par contre, aucune prise en charge de nodeJS. Et vue qu'on ne peut pas toucher à ce serveur, j'ai du souscrire un VPS (serveur mutualisé) sur lequel j'ai pu choisir l'OS et sa version et sur lequel j'ai également pu installer nodeJS et tout ce qui va avec.

J'ai testé 2 configuration pour mon application React. J'ai d'abord mis le front sur l'hébergement (celui qui est fourni d'office et non paramétrable) et le back sur mon VPS. Là j'ai eu un problème de CORS insoluble.
Ensuite j'ai tout mis sur le VPS, ce qui a nécessité de créer un serveur node supplémentaire pour traiter les requêtes vers le front. Là nouveau problème, galère sur les navigateurs car site "non sécurisé" car pas de certificat installé.

Ok, donc tu loues un premier serveur (que tu appelles hébergement) qui est pré configurer pour faire du apache/php/mysql je suppose (+un sftp/ftps pour déposer les fichiers)
Idéalement il faudrait pouvoir configurer apache pour qu'il fasse du proxypass vers ton VPS (mais sur un mutualisé je sais pas trop si c'est possible, faudrait se rapprocher de la doc / assistance de ton hébergeur)

Mais si tu loues un VPS, tu dois pouvoir tout faire directement dessus, par contre rien ne doit être pré configurer dessus et c'est à toi de tout installer et configurer.