以前也有類似的問題，他們都得出了AJAX不會過時的結論。但是，ajax比websockets更好？使用websocket/socket.io在哪裏Ajax會做的缺點是什麼？
使用socket.io，很容易回退到閃存或長輪詢，因此瀏覽器兼容性似乎不成問題。
Websockets是雙向的。如果Ajax會發出異步請求，websocket客戶端會向服務器發送消息。 POST/GET參數可以用JSON編碼。
那麼使用100％websockets有什麼問題？如果每個訪問者都保持與服務器的持久websocket連接，那麼比在整個訪問會話中提出幾個ajax請求會更浪費？
關於它沒有什麼「錯誤」。
唯一的區別是大多數可讀性。 Ajax的主要優點是它可以讓您快速開發，因爲大部分功能都是爲您編寫的。
每次打開套接字時都不必重新發明輪子，這是一個很大的優勢。
我認爲基於websocket的框架早晚會開始彈出，不僅僅是爲了編寫像web應用程序部分那樣的實時聊天，而且也是作爲獨立的web框架。一旦創建永久連接，它就可以用於接收各種東西，包括現在通過AJAX請求提供的Web應用程序的UI部分。這種方法可能會以某種方式傷害SEO，儘管它可以減少包含冗餘HTTP頭的異步請求所產生的流量和負載量。
但是我懷疑websockets會替換或危及AJAX，因爲有很多情況下永久連接是不必要或不需要的。例如，使用（一次性）基於REST的單一服務的混搭應用程序不需要與客戶端永久連接。
我認爲這會更浪費。對於每個連接的客戶端，您需要某種對象/功能/代碼/服務器上與該客戶端配對的任何內容。套接字處理程序或文件描述符，或者您的服務器設置爲處理連接。
使用AJAX，您不需要服務器端資源到客戶端的1：1映射。您的＃個客戶端可以比您的服務器端資源減少依賴性。即使node.js也有限制它可以處理並保持打開狀態的連接數。
要考慮的另一件事是某些AJAX響應也可以被緩存。隨着您向上擴展，您可以添加HTTP緩存來幫助減少頻繁的AJAX請求的負載。
就我個人而言，我認爲websockets將會越來越多地應用於web應用程序而不是AJAX。他們不太適合網站緩存和搜索引擎優化更受關注，但他們會爲webapps創造奇蹟。
DNode和socketstream等項目有助於消除複雜性並啓用簡單的RPC式編碼。這意味着你的客戶端代碼只是在服務器上調用一個函數，將任何數據傳遞給它想要的函數。服務器可以在客戶端調用一個函數並傳遞數據。你不需要關心TCP的基本問題。
此外，AJAX調用有很多開銷。例如，需要建立一個連接並在每個請求中都傳遞HTTP標頭（cookie等）。 Websockets消除了很多。有人說websockets更浪費，也許他們是對的。但我不相信這種差異真的很大。
我回答了另外一個相關的問題，包括很多相關資源的鏈接。你可能檢查出來：
WS：//連接比 「AJAX」 請求開銷少得多。
簡答
保持一個積極的WebSocket擁有成本，爲客戶端和服務器，阿賈克斯是否有一個成本只有一次，這取決於你用它做什麼。
長的答案
的WebSockets經常被誤解，因爲這個整體的「嘿，使用Ajax，會做！」。不，Websockets不能替代Ajax。他們可能會應用於相同的領域，但有些情況下使用Websocket是荒謬的。
我們來舉一個簡單的例子：在客戶端加載頁面後加載數據的動態頁面。很簡單，打一個Ajax電話。我們只需要一個方向，從服務器到客戶端。客戶端會詢問這些數據，服務器將把它們發送給客戶端，完成。你爲什麼要爲這樣的任務實現websockets？您不需要始終打開您的連接，您不需要客戶端不斷詢問服務器，也不需要服務器通知客戶端。連接將保持打開狀態，這會浪費資源，因爲要保持連接打開，您需要不斷檢查連接。
現在聊天應用程序的事情是完全不同的。您需要通過服務器通知您的客戶端，而不是強制客戶端每隔幾秒或幾毫秒詢問一次服務器是否有新問題。這是沒有意義的。
爲了更好地理解，請參閱兩個人。一個是服務器，一個是客戶端。 Ajax就像發送一封信一樣。客戶端發送一封信，服務器回覆另一封信。事實是，對於一個聊天應用程序，對話會是這樣的：
「嘿服務器，得到的東西對我來說
- 第
- 嘿服務器，得到的東西對我來說
-
號？ - 嘿服務器，給我找點東西嗎？
- 是的，就在這裏。「
如果客戶端從未要求答案，服務器實際上不能發送一封信給客戶端。這是一個巨大的資源浪費。因爲對於每個Ajax請求，即使它被緩存，您也需要在服務器端進行操作。
現在我前面討論過使用Ajax加載數據的情況。想象一下，客戶端正在與服務器通話。保持連接活動有成本。它耗費電力，你必須付錢給你的運營商。現在，如果你只是想讓這個人告訴你三個字，你爲什麼還需要給某人打電話並讓他打電話一個小時？發送一封該死的信。
總而言之，Websockets並非完全取代Ajax！
有時你會需要 Ajax其中Websocket的使用是荒謬的。
編輯：上證所情況下
技術是不使用很廣泛，但它可能是有用的。正如其名稱所述，Server-Sent Events是從服務器到客戶端的單向推送。客戶端不需要任何請求，服務器只是發送數據。
簡而言之：
- 從客戶端單向：阿賈克斯
- 單向從服務器：SSE
- 雙向：WebSockets的
正如其他人說，保持連接打開可以在某些情況下是矯枉過正你不需要服務器到客戶端的通知，或者客戶端到服務器的請求發生在低頻率的情況下。
但是另一個缺點是websockets是一種低級協議，一旦執行初始握手，就不會向TCP提供額外的功能。因此，當通過websockets實現請求 - 響應範例時，您可能會錯過HTTP（一種非常成熟和極端的協議族）提供的功能，如緩存（客戶端和共享緩存），驗證（條件請求），安全和冪等這對代理的行爲有影響），範圍請求，內容類型，狀態代碼......
也就是說，你可以減少消息的大小。
所以我的選擇是AJAX的請求 - 響應，如果你想服務器連接打開的WebSockets服務器推高頻率低延遲消息
，如果連續輪詢服務器將在那裏，然後去插座否則你很適合與阿賈克斯一起去。
簡單的類比： Ajax向服務器詢問問題（請求），服務器給出這些問題的答案（回答）。現在，如果你想問不斷的問題，那麼Ajax不會工作，它有一個大的開銷，這將需要資源在兩端。
我相信這是正確的。在不需要雙向通信的應用程序中，服務器上的ajax請求會更容易。另外，請考慮當HTML5脫機持久性變爲可用時（與Websockets變得更加可用的時間基本相同），Web應用程序只會根據需要與服務器同步。 – badunk 2012-03-17 09:06:24