OT: Where has this word Polyfill appeared from? I first read it yesterday and here it is again.

It's been in use for a while. In home repair, polyfills are used to fill in gaps and level out uneven surfaces. The term was adopted by web developers to refer to code that implements standard features in browsers that don't support them yet.

The last section is really important. If you don't need the full duplex communication of WebSockets, Server-Sent Events are a much better choice. If you can get away with using AJAX to update the server from the client, do it.

A fun side note about these: they're supported on the Wii's version of Opera. ;)

I wrote a very basic Node.js server to do this, which could in theory work well for 2-player games in the browser: https://github.com/ryanmcgrath/wii-js/blob/master/server.js

I wrote a partial implementation (no event types or useful IDs) of the server-side SSE protocol for kicks using nodejs (an old version of node, but it still seems to work):

http://github.com/shinetech/eventserver

Basically you can post JSON messages via HTTP & they're streamed in real time to clients via the Server-Sent Events protocol.

This is a great, simple protocol with a dead-simple client-side API -- I can see it being really popular as browser support for SSE and CORS improves: http://www.w3.org/TR/cors/

This is very interesting- I am developing a webapp that allows you to track other people's taxi journeys, and right now I'm AJAX polling every 30 seconds becuase I figured WebSockets would be too intensive on a phone (open connection = drained battery).

Does anyone know if this would also end up with an open connection the whole time?

Does an open connection with no data flowing really use more battery? I would imagine a 30-second polling interval is still frequent enough to keep the antenna in high-power mode, so it wouldn't make much of a difference. Have you found that not to be the case?

To be honest, I haven't been able to run any kind of reliable test, I was just working on "common knowledge".

Testing battery drain is, by it's nature, a kind of time-consuming exercise. Given that it's a relatively small piece of functionality I just haven't gotten around to it yet.

I would imagine it is using stream sockets , so yes (unless it's really just doing polling in the background).

What we really need is some way of doing UDP via javascript, this would enable many things.

EDIT: Why would I want someone else able to track my taxi journey?

With regard to your edit: so that they know where you are, essentially. There's a social aspect ("when are you getting to the bar?") as well as a safety one (travelling late at night, someone will always know where you are).

There's also some interesting benefits from my POV- it's effectively returning live data on the average mph on every street in the city. Relies on getting a decent number of users before being useful of course, but still.

Gratuitous plug for the site with more info: http://www.taxono.my/

Wouldn't Google Latitude do this, already?

To an extent, yes. But my app also sends over details like where the person is going to, which AFAIK Latitude doesn't do.

The app also lets you search for destinations, gives you a time and fare estimate, split the total between friends, review your cab ride... while the tracking stuff is a central feature, it isn't the only one.

SSE creates a persistent connection. On disconnect, the client will automatically attempt to reconnect.

James Coglan's Faye project (https://github.com/faye) contains some nice implementations of Server-Sent Events for Ruby and Node.

First, you seem to be confusing WebSockets, which is a protocol and low-level DOM interface for dealing with that protocol with Socket.io, which is a software framework for client-to-server messaging that uses WebSockets as one possible transport. (And pretty much has to take over your server entirely in order to work.) It's like reading an article about Rack and saying, "I don't see how this is any better than Ruby on Rails."

Now that that's out of the way: Strictly speaking, WebSockets are "better" than SSE in that you can do everything you can do with SSE using WebSockets. However, the SSE protocol:

* Is plain HTTP, instead of adding on a separate protocol,

* Has an easy-to-generate text-based format,

* Does not require major upgrades to your server, and

* Can be emulated on non-conforming browsers using standard XHR's.

So when all you need to do in realtime is send data from the server to the client (remember, you can still use XHR's to call back to your server), SSE is far easier to implement both on the client and on the server.