Poprawna odpowiedź to AJAX, bo właśnie ta technologia pozwala na komunikację z serwerem bez przeładowywania całej strony HTML. W praktyce chodzi o to, że skrypt JavaScript w przeglądarce wysyła żądanie HTTP (np. GET lub POST) do serwera w tle, pobiera dane (często w formacie JSON) i na ich podstawie aktualizuje tylko wybrane fragmenty dokumentu, modyfikując DOM. Użytkownik widzi wtedy płynne odświeżanie zawartości, bez irytującego migania strony. Moim zdaniem to jest jeden z kluczowych fundamentów nowoczesnych aplikacji webowych typu SPA i ogólnie tzw. „rich internet applications”. AJAX nie jest jednym konkretnym językiem, tylko podejściem/technicznym zestawem: HTML + CSS + JavaScript + obiekt XMLHttpRequest lub fetch() + protokół HTTP + najczęściej JSON lub czasem XML. Standardy W3C i WHATWG opisują m.in. API do wykonywania żądań asynchronicznych oraz manipulacji DOM, a dobre praktyki mówią, żeby logikę AJAX trzymać w oddzielnych modułach JS, stosować obsługę błędów, time-outy, a także unikać przeładowywania serwera zbyt częstymi zapytaniami. Przykład z życia: wyszukiwarka podpowiedzi w polu tekstowym (autocomplete w Google), dynamiczne ładowanie komentarzy pod artykułem, paginacja „dociągająca” kolejne rekordy po przewinięciu strony czy formularz, który po wysłaniu zwraca komunikat „zapisano” bez zmiany adresu URL. Z mojego doświadczenia dobrze napisany kod AJAX poprawia UX i zmniejsza transfer, bo zamiast całej strony przesyłamy tylko dane. W połączeniu z frameworkami typu React, Vue czy Angular AJAX jest podstawą komunikacji klient–serwer w aplikacjach webowych klasy enterprise.
W tym pytaniu łatwo się pomylić, bo wszystkie podane technologie w jakiś sposób kojarzą się z tworzeniem aplikacji webowych, ale tylko jedna opisuje mechanizm komunikacji bez przeładowania całej strony. Kluczowe jest zrozumienie różnicy między językiem programowania, frameworkiem backendowym a techniką asynchronicznej komunikacji po stronie przeglądarki. Django to framework działający po stronie serwera, napisany w Pythonie. Służy do obsługi logiki biznesowej, generowania szablonów HTML, pracy z bazą danych, routingu adresów URL itd. Samo użycie Django nie powoduje automatycznie, że strona staje się „dynamiczna bez przeładowania”. To, czy strona przeładowuje się w całości, zależy od tego, jak zachowuje się kod w przeglądarce, a nie od tego, jaki framework stoi po stronie serwera. Podobnie PHP to język skryptowy po stronie serwera. Generuje HTML, JSON lub inne odpowiedzi HTTP, ale komunikacja odbywa się standardowo: przeglądarka wysyła żądanie, serwer z PHP odsyła odpowiedź. Bez zastosowania JavaScript i mechanizmów asynchronicznych każda interakcja użytkownika, która wymaga kontaktu z serwerem, kończy się pełnym przeładowaniem dokumentu. Częsty błąd myślowy polega na tym, że skoro PHP „tworzy dynamiczne strony”, to odpowiada też za ich dynamiczne odświeżanie w przeglądarce. W rzeczywistości dynamika po stronie serwera i dynamika interfejsu w przeglądarce to dwie różne warstwy. Ruby również jest tylko językiem programowania, a w świecie webowym najczęściej używany jest z frameworkiem Ruby on Rails. Znowu – świetnie nadaje się do tworzenia API, generowania widoków, obsługi baz danych, ale sam z siebie nie rozwiązuje problemu komunikacji asynchronicznej w przeglądarce. Bez JavaScriptu i odpowiednich wywołań HTTP od strony klienta, strona w Ruby zachowuje się tak samo jak w przypadku PHP czy Django: każda odpowiedź to nowy dokument HTML. Sedno jest takie, że AJAX opisuje konkretną technikę po stronie klienta: asynchroniczne wysyłanie żądań HTTP z przeglądarki i aktualizowanie tylko fragmentów strony. Django, PHP i Ruby mogą być serwerowym „końcem” tych zapytań AJAX, ale nie są samą technologią odpowiedzialną za brak przeładowania strony. Rozdzielenie w głowie: frontendowa komunikacja asynchroniczna vs backendowa logika serwera, to bardzo ważna dobra praktyka w programowaniu webowym.