Myślę, że twoje pytanie może być dość specyficzne dla PHP, ponieważ nie widzę żadnej innej technologii zaplecza, o której wspominasz, jest wykorzystywana w ten sposób.
PHP jest zabawnym przykładem, ponieważ może być (w dość brzydki sposób mogę dodać) postrzegany jako język „wszystko w jednym” w odniesieniu do wielu projektów internetowych. Możesz wykonywać swoje tradycyjne zadania „ zaplecza ” - takie jak operacje na plikach i bazach danych, a także budować znaczniki „ front-end ”.
Może to oczywiście prowadzić do bałaganu spaghetti, w którym nie ma prawdziwego oddzielenia zmartwień, więc naprawdę powinienem się na to zgodzić. Na przykład, jeśli przeglądasz źródło wordpress, często możesz się zgubić - i to jest jeden projekt, w którym obwiniam język, organizacja bazy kodu jest w rzeczywistości bardzo dobra.
Można temu zaradzić, używając „ silnika szablonów ” (takiego jak Smarty )) - ale to wciąż PHP buduje „front-end”, a jednocześnie zapewnia funkcję „back-end”. To była celowa decyzja dotycząca projektu PHP, jednak jest to przecież „ procesor hipertekstowy ”!
Tak więc PHP może łatwo dopasować się zarówno do zastosowań „ front-end ”, jak i „ back-end ”, co powinno wyjaśnić twój przykład. Dlatego najprawdopodobniej masz rację, ponieważ PHP będzie przetwarzać i budować wszystkie narzuty na front-end, ale będzie wysyłać żądania w innym miejscu w celu zebrania wymaganych danych - najprawdopodobniej usługa napisana w jednym z wyżej wymienionych języków .
Osobiście uważam, że cała terminologia „back-end” i „front-end” jest nieco… może przestarzała. Wolałbym, żeby rzeczy były po prostu odnoszone do klienta i serwera; wtedy nie ma prawdziwej dwuznaczności. *
Ostatnio widziałem specyfikację klienta, która wymagała systemu zaplecza napisanego w node.js i powiązanych narzędziach, ale chciała kompilacji frontonu przy użyciu frameworka PHP (Laravel). Jest to związane z wieloma kosztami i moim zdaniem - nie jest eleganckim rozwiązaniem i może powodować sporo problemów.
Osobiście mówiąc, tego rodzaju konfiguracje wyglądają, jakby ktoś niepotrzebnie przeniósł PHP na inny stos - co oznacza, że potrzeba więcej zasobów, niż jest to faktycznie konieczne, personel konserwacyjny potrzebuje kontaktu z szerszą gamą technologii i jest więcej punktów awarii.
Ponadto uważam, że istnieje bardzo niewiele scenariuszy, które uzasadniają ten rodzaj stosu pośredniego; większość języków / frameworków zaplecza jest w pełni zdolna do generowania narzutów wymaganych dla interfejsu. Chociaż mogę tam zostać poprawiony.
* Jednak, aby odrzucić twoje pytanie. Co z systemami back-endowymi zbudowanymi przy użyciu Javascript? (node.js;))
Edytować:
Po przeczytaniu komentarza @itsbruce postanowiłem wyjaśnić, co rozumiem przez niejednoznaczność mojej terminologii „front-end” / „back-end”.
Tradycyjnie ta terminologia byłaby w porządku, architektonicznie aplikacje internetowe byłyby o wiele prostsze - i śmiem to powiedzieć, dużo głupsze. Moim zdaniem dużo czystsze jest mówienie „po stronie serwera” i „po stronie klienta”, a staje się to wyraźniejsze, gdy obecny trend przekazywania większej liczby procesów przetwarzania i logiki klientowi staje się powszechny.
Dopuszczalne jest wykonywanie sporej ilości przetwarzania danych po stronie klienta (wystarczy spojrzeć na niektóre z popularnych obecnie modów javascript), ale czy to naprawdę front-end? Użytkownik nie widzi tego, widzi jego wyniki - i według tradycyjnych kryteriów, które na ogół byłyby postrzegane jako „zaplecze”; ale teraz dzieje się to w przeglądarce ...
Podobnie i niezwykle istotne dla tego pytania, czy budowanie marży w PHP jest naprawdę zadaniem front-end? Wątpię, szybkie przeglądanie ofert pracy pokazuje, że niewiele stanowisk front-endowych programistów oczekuje doświadczenia w PHP lub wiedzy; jednak intuicja sugerowałaby, że narzut dla interfejsu jest z natury frontendem.
Sam fakt, że pytanie to istnieje, stanowi przykład tego, jak „ front-end ” i „ back-end ” są z natury niejednoznaczne i tak pozostanie.
Mówiąc o zadaniach „po stronie serwera” lub „po stronie klienta”, że niejednoznaczność zostanie utracona, wiesz, gdzie wykonuje się kod i jakie języki będą używane. Jeśli powiedziałeś „ front-end ” w przykładzie podanym przez OP, wątpię, by wiele osób powiedziałoby „ Och, więc PHP na serwerze, prawda? ”.