Problem jest tu tylko jeden, ale za to poważny - serwery proxy "po drodze" muszą odpowiednio rozumieć ten mechanizm, a to zależy już od konfiguracji usługi proxy, czyli od administratora. W przypadku AJAX-a mechanizmy proxy mogą jedynie przechowywać wynik przesyłany z serwera, ale przekazywany strumień może nie zawierać odpowiednich nagłówków. Kolejna kwestia związana z AJAX-em to dostępność dla osób niepełnosprawnych. Zdaję sobie sprawę, że w Polsce naprawdę nieliczne witryny są pisane z myślą o przeglądarkach "głosowych" (czyli m.in. tak, że każdy obrazek ma odpowiedni znacznik, który można przeczytać itp.).

W Stanach Zjednoczonych jest to wymagane przynajmniej w stosunku do szeroko pojętych stron rządowych. Tak zwane screen readery od pewnego czasu radzą sobie dobrze nawet z normalnymi z aplikacjami okienkowymi - system Windows implementuje odpowiednie interfejsy API pozwalające wskazać, jak dany element ma być przedstawiony osobie niepełnosprawnej.

Zaletą tych znaczników jest to, że niewielkim wysiłkiem istniejący interfejs graficzny może zostać odczytany przez odpowiednie oprogramowanie konwertujące tekst na mowę. W przypadku aplikacji AJAX nie ma możliwości prostej konwersji, ponieważ zmienia się cała filozofia interfejsu użytkownika. W takim wypadku trzeba by po prostu równolegle wykonać stronę funkcjonalnie równoznaczną, ale zgodną z wymaganiami "głosowymi". Pytanie: kto przeznaczy na to dodatkowe zasoby?

Podobny problem z elastycznością jest w przypadku urządzeń przenośnych. Jeżeli do liczby przeglądarek na "zwykłe" komputery doliczyć choćby tylko kilka głównych odmian interfejsów, z których każdy implementuje jakiś podzbiór JavaScript, to stopień złożoności kodu obsługującego taką różnorodność platform będzie naprawdę imponujący. A do tego warto pamiętać, że są serwery, które "konwertują" treść (X)HTML do postaci zrozumiałej przez urządzenie mobilne. Co taki serwer może zrobić z kodem aplikacji AJAX-em? Odpowiedź jest prosta: nic.

Projektant aplikacji opartej na AJAX zakłada, że połączenie z serwerem jest ciągle dostępne. Serwer musi cały czas identyfikować klienta, a dane są częściowo w przeglądarce, częściowo na serwerze. Jeśli połączenie sieciowe zniknie, nic się niby nie stanie, bo jednym z założeń AJAX-a jest to, że informację gromadzi serwer i komunikacja jest asynchroniczna, ale... Taką sytuację trzeba umiejętnie obsłużyć w przeglądarce. W praktyce trzeba napisać odpowiedni kod JavaScript i przetestować go. No i jeszcze, jeżeli trzeba zapisać coś lokalnie, to kod JavaScript musi mieć prawo do zapisu, co zwykle "irytuje" programy antywirusowe. Można też kombinować z przechowywaniem danych lokalnie w plikach cookie, jak jest to rozwiązane w serwisie Gmail, ale czy tak właśnie ma wyglądać przyszłość aplikacji?

Kosztowne udawanie

Jeżeli już trzeba stworzyć aplikację z asynchroniczną komunikacją z serwerem, to znacznie lepiej osadzić w przeglądarce aplet Java, uruchomić kod .Net, czy nawet napisać kod w ActionScript (Flash). Innymi słowy użyć środowiska, które pozwala programiście nie tylko zaimplementować pewną funkcjonalność, ale także przetestować ją dokładnie w ramach rozsądnego czasu. Java, .Net i ActionScript pozwalają w elegancki sposób wywołać usługę Web i obsłużyć XML z pilnowaniem typów (zdefiniowanych za pośrednictwem WSDL). Dostępne są też narzędzia IDE do śledzenia aplikacji, testowania, kontroli jakości itp.

W przypadku utraty połączenia z serwerem mamy wtedy do dyspozycji cały arsenał mechanizmów pozwalających przechować lokalnie wykonaną pracę w postaci XML lub przez mechanizmy replikacyjne, a w każdym razie coś, co jest już znane, przetestowane i wiadomo jak się tym posłużyć. Jeżeli do tego zostanie dodana asynchronicznie wywoływana usługa Web, to otrzymamy bardzo wygodny interfejs, który, co ważne, powstanie niewielkim kosztem.

Jedyna sytuacja, jaka przemawia za stosowaniem AJAX-a, to taka, w której firma chce zaoferować pewną funkcjonalność szerokiej publiczności korzystającej z różnych platform, różnych przeglądarek i ich wersji. Wtedy właśnie JavaScript okazuje się po prostu "najmniejszym wspólnym mianownikiem" dla tej różnorodności, działającym na każdym desktopie i w każdej przeglądarce.

Ale czy Java nie oferuje tego samego i to przy znacznie mniejszym bagażu problemów? A Flash? Przeglądarka bez zainstalowanego Flasha jest dla zwykłego użytkownika w sumie mało przydatna... Warto też zauważyć, że trochę nieekonomiczne jest traktowanie komputera z 512 MB RAM, procesorem, powiedzmy 2 GHz, jako "cienkiego" klienta. Słabsze modele trudno dziś kupić, a na pewno w przypadku masowego odbiorcy na słabszym modelu znacznie gorzej działają gry, więc...

Podsumowując, jeżeli AJAX ma być przyszłością oprogramowania, to z wielu powodów wygląda na to, że w świecie WWW, gdzie wreszcie XHTML zaczął być prawdziwym standardem opisu strony, pojawia się nowy potworek. A tak naprawdę to będzie po prostu "udawanie" normalnego, bogatego klienta. Olbrzymim kosztem.