I just started researching HTML5 WebSockets. I was wondering whether I can update all of a web page's content with websockets instead of using ASP.NET UpdatePanels, or would this be overkill?
Can WebSockets be used as a replacement for AJAX? And is this what WebSockets should be used for?
Most of the examples are for bi-directional chat-like demos. But if I wanted to click a button and not postback to update a grid, could I do this with WebSockets and would that be a good idea?
I think XHR and WebSocket are for 2 different scenarios and you should use the one better fits your scenario.
XHR has the request-response pair. Each request is paired with a response. This is good for remote procedure call, but creates unnecessary overhead if you want response without request (i.e. server push).
WebSocket solves the problem above. You can send a request without expecting any response. The server can also send you anything via response without you initiating a request first.
In a button clicking and content updating scenario (e.g. editing table cells), XHR (and UpdatePanel) works better. That's because the content updating has to be paired with a button clicking. This is a request-response pair. But in a pure content updating scenario (e.g. displaying real-time stock price), WebSocket works better. In a scenario in which content updating isn't related to button clicking (e.g. chatting), WebSocket also works better.
The WebSocket standards are designed for applications that need low-latency, low-overhead communication. They are good for existing applications that are pushing the limits of what is possible with AJAX/Comet/long-poll. But even more importantly, WebSockets will enabled a whole new class of web applications that don't exist yet.
For your case, it sounds like WebSockets would probably be overkill since latency isn't a core issue in what you are building. You certainly could do it with WebSockets, but I suspect that would be extra work for very little gain in your case.
See this answer for why WebSockets are already ready for general use (with web-socket-js and native iOS support this means that WebSockets are supported on pretty much all browsers in the wild).
If you want to use WebSockets in a page that IE8 should be able to view, use Ajax instead.
WebSockets were originally designed for fast, two-way communication between client and server. It was very important to have this for games to flourish in the browser, but the server-side implementation is not fully standardized yet -- there may be further security complications.
Right now, WebSockets are only used for toy implementations. They are not customer-ready. Also, they really are necessary only when Ajax calls and Comet calls are too slow for your needs.
Technically, yes. Practically, I'd probably wait.
Websockets are definitely the way HTML5 does the type of communication we're used to. Technically, yes you can, but depending on the type of site you're building, you might want to hold off. Websockets is one of the newer pieces of the HTML5 spec and is still being finalized. It works in the newest versions of Chrome and Firefox 4, but IE9 doesn't have this implemented yet, and there's no word on if IE10 will have it either. Technical sites that show off the newest technology (like demoing what is possible in HTML5) and any other things where the vast majority of the audience will be guaranteed to use a supporting browser or are early adopters should be fine. If not, you may be alienating some users. Only you can decide which way to go.
The key here is that Websockets is a changing spec currently, and AJAX works in both old and new browsers. If you want backwards compatable in addition to a guarantee the spec and browsers won't change tomorrow and break your exisisting code, use AJAX. If you're cool with a slight possibility that the spec and browser implementations may change in the future and don't care about people using older browsers, then use websockets.
Another stackoverflow answer shows websocket support:
