Czy jest to zgodne ze sztuką? - PHP, Ajax

Question

Cześć piszę aplikację webową przy użyciu PHP, Javascript - nasuwa mnie się pytanie, otóż wiem że jest to wykonalne i działa, ale czy zgodne ze sztuką jest przesyłanie AJAXem wygenerowanego przez backend HTMLa i wyświetlanie go użytkownikowi? Zwykle przesyłałem dane w JSONie i sklejałem je po stronie klienta, lecz chciałbym wiedzieć czy poprostu metoda wysyłania wyrenderowanych widoków jest "etyczna".

Pozdrawiam.

Comments

W grze online anocris.com, kod do okien informacyjnych jest przesyłany przez fetch w postać html-a widać to w DEVTools na request-ach . Sama gra jest "rysowana" w <canvas> albo <img> z <map>, duża część kodu html (nawet po kilka KB na 1 request) jest fetch-owana (jak już pisałem powyżej ) i śmiga to przyzwoicie.

Answer 1

Nie wiem co napiszą koledzy, ale generowanie HTMLA z backendu,  w ogóle nie będzie dobra praktyką, pomijam fakt jak ogromny PAYLOAD danych to musi być na request, już abstrahując od tego, czy jest to robione AJAXem, czy inną technologią np. intefejsu fetch,  API  czy jakiś XMLHttpRequest 

Dlaczego cały HTML leci do sklejenia w requeście? Dlaczego trzymasz HTML na backendzie, w ogole jak w takim razie to aktualizujesz? 

Widok renderuje się na frontendzie, może być związany z bazą ale sama warstwa Klienta, odpowiada za kontent 

Comments

Troche nieprezycyjnie się wyraziłem, szablony widoków generuję na zasadzie podobnej do BLADE'a używanego w Laravelu.

A o sklejaniu po stronie klienta miałem na myśli generowanie dodatkowego kontentu za pomocą funkcji Javascriptu. Tj. klient odbiera JSONa z danymi i na podstawie tych danych generowany jest odpowiedni szablon widoku. tj. okno modalne czy inne powiadomienie.

Proszę wybaczyć nieprezycyjne słownictwo lecz nie mam z kim dyskutować na temat takich spraw, także pojęcia którymi się posługuje nie oddają często tego co mam na myśli.

---

@Wiciorny, 

Widok renderuje się na frontendzie, może być związany z bazą ale sama warstwa Klienta, odpowiada za kontent 

No nie, pełny rendering po stronie klienta od wieków jest uznawany za mniej wydajny. Dlatego praktycznie każdy framework JS-owy w ostatnich 2-3 latach wynalazł SSR na nowo. Stąd zresztą mamy rozwiązania fullstackowe pokroju Next.js.

---

ja to zrozumiałem w inny sposób, że "kontent dynamiczny" jest renderowany z bazy i o to mi chodziło, a nie np model SSG, gdzie mamy częsci statyczne, lub backend renderuje dane na stronie w zależności od odp. ja to zrozumiałem jako przechowywanie czystego HTML w bazie i ładowanie tego na zasadzie requestu.
Co wydawało mi się absurdalne.

Rozumiem, że SSR sposób się zmienił? Gdyż przecież CSR znacznie później przyszedł niż model SSR, bo ten jest najstarszy i pierwszy.

---

To trzymanie gotowego HTML-a w bazie faktycznie jest kiepskie. Ale już przesyłanie HTML-a w odpowiedzi np. na Ajaksowe zapytanie jest obecnie normalną praktyką.

Rozumiem, że SSR sposób się zmienił? Gdyż przecież CSR znacznie później przyszedł niż model SSR, bo ten jest najstarszy i pierwszy.

Tak, ale wraz z nadejściem Angular.js i pierwszych wersji Reacta nagle o nim zapomniano i dopiero trzeba było kilku lat, żeby na nowo się pojawił. 

---

Okej dzieki, jednak dalej w praktyce zauważam, że wiele stron i projektów dalej leci na technologiach Angulara/Reacta0( chociaż ten drugi SSR może implementować dosyć czytelnie)  i korzysta z rozwiązań CSR, nie zauważam popularności np. Next.js żeby od razu mówic o SSR

---

State of JS pokazuje jednak wyraźny trend.

Answer 2

Owszem, jest zgodne ze sztuką. Ba, obecnie ta technika powoli wraca do łask dzięki rozwiązaniom pokroju Hotwire. Z dużych aplikacji to np. GitHub działa w podobny sposób od dawna.