Front-end écrit dans les langues utilisées pour le back-end!
D'après mon expérience dans le développement web, je sais que des langages comme PHP, Java, Python..etc sont utilisés pour les trucs de développement backend (logiciel qui s'exécute sur le serveur), et pour les langages frontaux, JS/HTML/CSS sont utilisés.
Mais je vois de nombreuses entreprises dire qu'elles utilisent, par exemple, PHP pour le développement front-end et python pour le back-end).
Est-ce à dire PHP est le front-end pour appeler d'autres services écrits dans d'autres langues via REST, RPC ..etc?
Vous avez confondu les termes "front-end" et "back-end" avec "côté serveur" et "côté client". "Back-end" se réfère généralement aux systèmes qui ne sont pas directement exposés à l'utilisateur (serveurs de base de données, middleware, etc.), tandis que "front-end" se réfère généralement à l'application (dans le cas du Web, cela signifie normalement statique et pages Web dynamiques) accessibles directement par le client.
Dans une application Web, le client (le navigateur de l'utilisateur) accède à des pages Web qui sont stockées ou générées dynamiquement "côté serveur" par des technologies "frontales". Ces composants frontaux peuvent, à leur tour, extraire des données ou d'autres informations des composants "principaux". Ainsi, une application Web écrite en PHP serait "front-end" mais "côté serveur". Cependant, si les pages Web contenaient du javascript à exécuter par le navigateur de l'utilisateur, que le code javascript serait exécuté "côté client".
J'espère que j'ai éliminé une certaine confusion, mais maintenant je risque d'en créer plus.
Tout d'abord, nous avons AJAX , qui est du code (généralement JavaScript) exécuté dans le client (donc côté client), pour créer les pages Web que vous voyez en tirant informations provenant de services accessibles sur Internet qui ne génèrent pas eux-mêmes des pages Web. Les services génèrent leurs informations côté serveur sur le front-end (car ils sont publics et vous pouvez pointer votre navigateur directement vers eux si vous connaissez l'url).
Deuxièmement, JavaScript n'est pas limité à l'utilisation côté client, bien sûr. Il est devenu de plus en plus populaire en tant que langage "côté serveur" (voir node.js pour un exemple). En tant que tel, son utilisation la plus courante concerne uniquement le type de services accessibles sur Internet que j'ai décrit dans le paragraphe précédent.
Les choses étaient beaucoup plus simples avant Web 2. . À l'époque, dans le contexte des applications Web , le front-end était l'endroit où les pages Web étaient générées, tandis que JavaScript ne s'exécutait que côté client et rendait les cosmétiques mineurs pour des pages Web telles que des images très éclairées lorsque vous déplacez la souris dessus. Cependant, cette simplicité a rendu les gens paresseux au sujet de leurs définitions. Maintenant, la situation est plus complexe, il est donc important d'être précis sur ces termes.
(Oh, et si vous avez pour utiliser PHP, veuillez le garder sur le front-end. Il est catégorique pas une bonne technologie back-end. Et si jamais vous trouvez quelqu'un qui crée un navigateur qui exécute PHP côté client, tirez-le.)
Je pense que votre question peut être très spécifique à PHP vraiment, car je ne vois aucune des autres technologies back-end que vous mentionnez être utilisée 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 traditionnelles " back-end", telles que les opérations sur les fichiers et les bases de données, tout en créant également le balisage " 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 résolu, quelque peu, en utilisant un " moteur de modèles" (comme Smarty )) - mais c'est toujours PHP qui construit le "front-end" tout en fournissant également la fonctionnalité "back-end". C'était une décision intentionnelle derrière la conception de PHP cependant, c'est après tout un "processeur hypertexte "!
Donc PHP peut facilement s'adapter aux utilisations " front-end" et " back-end", qui devraient clarifiez votre exemple. Par conséquent, vous avez très probablement raison en ce que PHP traitera et construira toutes les balises pour un front-end, mais il fera des demandes ailleurs pour rassembler les informations requises) données - très probablement un service a écrit dans l'une des langues susmentionnées.
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). de nombreux coûts associés, et dans mon esprit - n'est pas une solution élégante et peut causer quelques problèmes sur toute la ligne.
Personnellement, ce type de configurations semble que quelqu'un a inutilement chausse-pied 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 éventail plus large de technologies et il y a plus de points d'échec.
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 .. Qu'en est-il des systèmes dorsaux construits en utilisant Javascript? (node.js;))
Modifier:
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 dans PHP est-elle vraiment une tâche frontale? J'en doute, une navigation rapide sur les sites d'offres d'emploi montre peu de postes de développeur frontaux attendez PHP expérience ou connaissance; pourtant l'intuition suggérerait que le balisage pour 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 à soyez ainsi.
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 iraient " Oh, alors PHP on le serveur n'est-ce pas? ".