Comparatif PHP/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.

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.

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