Acho que sua pergunta pode ser bastante específica para o PHP, pois não consigo ver nenhuma das outras tecnologias de back-end mencionadas sendo usadas dessa maneira.
O PHP é um exemplo engraçado, pois pode ser (de uma maneira bastante feia, devo acrescentar) visto como uma linguagem tudo-em-um no que diz respeito a muitos projetos da web. Você pode executar suas tarefas tradicionais de " back-end " - como operações de arquivo e banco de dados, além de criar marcações de " front-end ".
Isso pode claramente levar a uma bagunça de espaguete, onde não há uma separação real de preocupação, por isso realmente deve ser desaprovada em minha mente. Por um ótimo exemplo, se você procurar a fonte do wordpress, pode se perder - e esse é um projeto em que culpo a linguagem, a organização da base de código é realmente muito boa.
Isso pode ser remediado, de certa forma, usando um " mecanismo de modelo " (como o Smarty )) - mas ainda é o PHP que está construindo o "front-end", além de fornecer a funcionalidade "back-end". Esta foi uma decisão intencional por trás do design do PHP, no entanto, é afinal um " processador de hipertexto "!
Portanto, o PHP pode se encaixar facilmente nos usos " front-end " e " back-end ", o que deve esclarecer seu exemplo. Portanto, você provavelmente está certo de que o PHP processará e criará toda a marcação para um front-end, mas fará solicitações em outro lugar para reunir os dados necessários - provavelmente um serviço gravado em uma das linguagens mencionadas acima .
Pessoalmente, acho que toda a terminologia "back-end" e "front-end" está um pouco ... desatualizada. Prefiro que as coisas se refiram apenas ao lado do cliente e do servidor; então não há ambiguidade real. *
Recentemente, vi uma especificação de cliente que exigia um sistema de back-end escrito em node.js e ferramentas associadas, mas queria a compilação de front-end usando uma estrutura PHP (Laravel). Isso vem com muitos custos associados e, em minha opinião, não é uma solução elegante e pode causar alguns problemas na linha.
Pessoalmente, esse tipo de configuração parece que alguém transferiu o PHP desnecessariamente para outra pilha - o que significa que são necessários mais recursos do que realmente são necessários, a equipe de manutenção precisa de exposição a uma gama mais ampla de tecnologias e há mais pontos de falha.
Além disso, também acho que existem muito poucos cenários que justificam esse tipo de pilha intermediária; a maioria das linguagens / estruturas de back-end é perfeitamente capaz de gerar a marcação necessária para o front-end. Embora eu deva ser corrigido lá.
* Porém, para deixar sua pergunta de cabeça para baixo. E os sistemas de back-end criados com Javascript? (node.js;))
Editar:
Depois de ler um comentário do @itsbruce, decidi esclarecer o que quero dizer com a ambiguidade da minha terminologia "front-end" / "back-end".
Tradicionalmente, essa terminologia teria sido boa, os aplicativos da Web da arquitetura eram muito mais simples - e ouso dizer, muito mais burros. É muito mais limpo em minha mente dizer "Lado do Servidor" e "Lado do Cliente", e isso está ficando mais claro à medida que a tendência atual de empurrar mais do processamento e da lógica para o cliente está se tornando comum.
Está se tornando aceitável fazer uma quantidade razoável de processamento de dados no lado do cliente (basta olhar para algumas das estruturas de javascript atualmente em alta), mas isso é realmente um front-end? O usuário não vê, vê os resultados - e por critérios tradicionais que geralmente seriam vistos como "back-end"; mas isso está ocorrendo no navegador agora ..
Da mesma forma, e incrivelmente relevante para essa questão, construir a marcação no PHP é realmente uma tarefa de front-end? Duvido, uma rápida navegação nos quadros de tarefas mostra poucas posições de desenvolvedor front-end que esperam experiência ou conhecimento em PHP; ainda assim, a intuição sugere que a marcação para a interface é inerentemente front-end.
O próprio fato de essa pergunta existir serve como um exemplo de como " front-end " e " back-end " são inerentemente ambíguos e continuarão sendo.
Ao se referir a tarefas como "do lado do servidor" ou "do lado do cliente" que perdem a ambiguidade, você sabe onde o código está sendo executado e quais idiomas serão usados. Se você disse " front-end " no exemplo que o OP forneceu, duvido que muitas pessoas digam " Ah, então PHP no servidor, certo? ".