Je pense que votre question peut être très spécifique à PHP, car je ne vois aucune des autres technologies back-end que vous mentionnez être utilisées comme ça.
PHP est un exemple amusant car il peut être (d'une manière plutôt laide je peux ajouter) considéré comme un langage tout-en-un en ce qui concerne de nombreux projets Web. Vous pouvez effectuer vos tâches " back-end " traditionnelles - telles que les opérations de fichiers et de bases de données, tout en créant une balise " front-end ".
Cela peut clairement conduire à un gâchis de spaghetti où il n'y a pas de véritable séparation des préoccupations, donc cela devrait vraiment être mal vu dans mon esprit. Pour un excellent exemple, si vous parcourez la source wordpress, vous pouvez souvent vous perdre - et c'est un projet où je blâme la langue, l'organisation de la base de code est en fait très bonne.
Cela peut être corrigé, quelque peu, en utilisant un " moteur de modèle " (comme Smarty )) - mais c'est toujours PHP qui construit le "front-end" tout en fournissant également la fonctionnalité "back-end". Ce fut une décision intentionnelle derrière la conception de PHP cependant, c'est après tout un " processeur hypertexte "!
PHP peut donc facilement s'adapter aux utilisations " front-end " et " back-end ", ce qui devrait clarifier votre exemple. Par conséquent, vous avez très probablement raison en ce que PHP traitera et construira toutes les balises pour un frontal, mais il fera des demandes ailleurs pour recueillir les données requises - très probablement un service écrit dans l'un des langages susmentionnés .
Personnellement, je pense que toute la terminologie "back-end" et "front-end" est un peu .. dépassée peut-être. Je préfère que les choses soient simplement référencées côté client et côté serveur; alors il n'y a pas de véritable ambiguïté. *
Très récemment, j'ai vu une spécification client qui nécessitait un système back-end écrit dans node.js et les outils associés, mais je voulais la construction front-end en utilisant un framework PHP (Laravel). Cela s'accompagne de nombreux coûts associés et, à mon avis, ce n'est pas une solution élégante et peut causer quelques problèmes en fin de compte.
Personnellement, ce type de configurations semble que quelqu'un a inutilement intégré PHP dans une autre pile - ce qui signifie que plus de ressources sont nécessaires que ce qui est réellement nécessaire, le personnel de maintenance doit être exposé à un plus large éventail de technologies et il y a plus de points de défaillance.
De plus, je pense également qu'il y a très peu de scénarios qui justifient ce type de pile intermédiaire; la plupart des langages / frameworks back-end sont parfaitement capables de générer le balisage requis pour le front-end. Bien que je sois corrigé là-bas.
* Bien que, pour tourner votre question sur sa tête. (node.js;))
Éditer:
Après avoir lu un commentaire de @itsbruce, j'ai décidé de clarifier ce que je veux dire par l'ambiguïté de ma terminologie "front-end" / "back-end".
Traditionnellement, cette terminologie aurait été bonne, les applications Web architecturales étaient beaucoup plus simples - et j'ose le dire, beaucoup plus stupides. C'est beaucoup plus propre dans mon esprit de dire «côté serveur» et «côté client», et cela devient plus clair à mesure que la tendance actuelle à pousser davantage le traitement et la logique vers le client devient courante.
Il devient acceptable de faire une bonne quantité de traitement de données côté client (il suffit de regarder certains des cadres javascript actuellement en vogue), mais est-ce vraiment frontal? L'utilisateur ne le voit pas, il en voit les résultats - et selon des critères traditionnels qui seraient généralement considérés comme des "back-end"; mais cela se produit dans le navigateur maintenant ..
De même, et incroyablement pertinent pour cette question, la construction du balisage en PHP est-elle vraiment une tâche frontale? J'en doute, une navigation rapide sur les sites d'offres d'emploi montre que peu de postes de développeurs frontaux attendent une expérience ou des connaissances PHP; pourtant, l'intuition suggère que le balisage de l'interface est intrinsèquement frontal.
Le fait même que cette question existe constitue un exemple de la façon dont " front-end " et " back-end " sont intrinsèquement ambigus et continueront de l'être.
En faisant référence aux tâches comme «côté serveur» ou «côté client», cette ambiguïté est perdue, vous savez où le code s'exécute et quelles langues seront utilisées. Si vous avez dit " front-end " dans l'exemple fourni par l'OP, je doute que beaucoup de gens diraient " Oh, alors PHP sur le serveur n'est-ce pas? ".