Jedno i drugie ma rację bytu obok siebie, nie zamiast. XMLHttpRequest oraz WebSocket pomimo pozornego podobieństwa zastosowań moją inne zadania.

Asynchroniczne żądania do serwera (AJAX) mają za zadanie, bez przeładowywania dokumentu, dostarczyć do niego dane. Żądania te będą (prawie) zawszę odpowiedzią na akcję użytkownika.

Sytuacja: chcemy po wypełnienie formularza, walidować dane w jego polach (np. sprawdzić czy login już jest zajęty). Po kliknięciu na przycisk wysyłający formularz (ewentualnie, po wyjściu z pola login), przeglądarka przygotowuję asynchroniczne żądanie do serwera, wypełniając je danymi z formularza. Po wysłaniu żądania, przeglądarka w odpowiedzi na nie wykonuje kod, który sprawdza odpowiedź (od serwera) i na podstawie tego generuje i umieszcza komunikat obok pola.

Należy pamiętać, że protokół HTTP jest protokołem bezstanowym (http://pl.wikipedia.org/wiki/Hypertext_Transfer_Protocol), to oznacza, że tylko przeglądarka może nawiązać komunikację z serwerem, po przez wysłanie żądania, na które serwer odpowiada. Z punktu widzenia serwera, każde z żądań jest nie zależną, niepowiązaną ze sobą komunikacją.

To powoduje kilka problemów, a rozwiązaniem jednego z nich jest WebSocket.
Niektóre aplikację przeglądarkowe wymagają aktualności danych (np. aplikacje webmaila, chat itd.). W momencie, kiedy na serwerze pojawi się nowa wiadomość dla naszej skrzynki, czy nowa wiadomość na czacie, żeby przeglądarka mogła ją załadować musi się o niej jakoś dowiedzieć (serwer nie może jej wprost poinformować).

W związku z tym wymyślono kilka technik:

Pooling: Polega na tym, że przeglądarka, co zadanych interwał czasowy (np. co pół sekundy), wysłała do serwera, asynchroniczne żądanie z pytaniem „czy jest coś nowego dla mnie”. Jeśli na któreś z tych żądań serwer odpowie twierdząco, przeglądarka ładuję aktualny zestaw.

Rozwiązanie to ma wiele wad. Najważniejsze to brak prawdziwej aktualności danych oraz obciążanie serwera wieloma żądaniami.

Long pooling: Podobnie jak wcześniej, przeglądarka wysyła do serwera żądanie sprawdzające, czy jest coś nowego. Z tym, że jest ono tak skonfigurowane, aby nie miało timeouta, (czyli czasu, po którym przeglądarka zamknie połączenie, z powodu braku odpowiedzi). Na serwerze takie żądanie jest przetrzymywane (serwer nie generuje odpowiedzi natychmiast) tak długo, aż dla tej przeglądarki nie pojawi się coś nowego, wtedy serwer odpowiada, przeglądarka aktualizuje dane i wysyła nowe żądanie pytające o nowości.

Czyli jest to technika, która powoduje, że między przeglądarką jest stałe połączenie i to serwer decyduje, kiedy coś nim, do przeglądarki prześlę. Między innymi gmail korzysta z tej techniki.

Rozwiązanie to, ma oczywiście wady. Największą jest obciążenie serwera. Może to doprowadzić do wyczerpania się jego zasobów. 

WebSocket: W specyfikacji HTML 5, pojawiło się API, które tego typu problemu ma rozwiązywać. Wykorzystuję on protokół http do nawiązania obustronnego połączenia z serwerem. Te połączenie to tzw. full duplex, czyli podobnie jak w przypadku rozmowy telefonicznej, jedna i druga strona może nadawać, tak długo jak połącznie jest otwarte.
Podsumowując, WebSocket, to coś, co ma pozwolić serwerowi, przesyłać do naszej przeglądarki aktualne informację.

Oczywiście, technicznie jest możliwe, aby całość komunikacji protokołu HTTP zstąpić WebSocetem, w praktyce należy pamiętać, że jedno i drugie służy, do czego innego oraz posiada odrębne ograniczenia.