Server-Sent Events are real-time events emitted by the server and received by the browser. They’re similar to WebSockets in that they happen in real time, but they’re very much a one-way communication method from the server.

These events are similar to ordinary JavaScript events that occur in the browser — like click events — except we can control the name of the event and the data associated with it.

All the code for this article is available on github, and a live demo is available online.

† Is it Server-Sent Events or EventSource? Well, they both work. Server-Sent Events is the name of the API and specification. EventSource is the name of the JavaScript object you’re instantiating. It’s a bit like Ajax and XHR, where XHR refers to the XMLHttpRequest object…kinda.

Two notes: a) the uptime for this example is, I’m afraid, usually rather low — good for my server, bad for you. If you test the demo locally it will give you more interesting figures. b) IE6 isn’t supported in any of this article.

var source = new EventSource('/stats');
source.onopen = function () {
  connectionOpen(true);
};

source.onerror = function () {
  connectionOpen(false);
};

source.addEventListener('connections', updateConnections, false);
source.addEventListener('requests', updateRequests, false);
source.addEventListener('uptime', updateUptime, false);

source.onmessage = function (event) {
  // a message without a type was fired
};

data: this is a simple message
<blank line>

data: this is line one
data: and this is line two

id: 33
data: this is line one
data: this is line two

id: 34
data: Remy is awesome

id: 35
data: Bruce is stinky

id: 36
event: price
data: 103.34

id: 37
event: news
data: Bruce sells his collection of replica bananas

function stats(request, response) {
  // only response to an event-stream if the request 
  // actually accepts an event-stream
  if (request.headers.accept == 'text/event-stream') {

    // send the header to tell the client that we're going
    // to be streaming content down the connection
    response.writeHead(200, {
      'content-type': 'text/event-stream',
      'cache-control': 'no-cache',
      'connection': 'keep-alive'
    });

    // support the polyfill - we'll come on to this later
    if (request.headers['x-requested-with'] == 'XMLHttpRequest') {
      response.xhr = null;
    }

    // if there was a lastEventId sent in the header, send
    // the history of messages we've already stored up
    if (request.headers['last-event-id']) {
      var id = parseInt(request.headers['last-event-id']);
      for (var i = 0; i < history.length; i++) {
        if (history[i].id >= id) {
          sendSSE(response, history[i].id, history[i].event, history[i].message);
        }
      }
    } else {
      // if the client didn't send a lastEventId, it's the
      // first time they've come to our service, so send an
      // initial empty message with no id - this will reset
      // their id counter too.
      response.write('id\n\n');
    }

    // cache their connection - the response is where we write
    // to send messages
    connections.push(response);

    // send a broadcast message to all connected clients with
    // the total number of connections we have.
    broadcast('connections', connections.length);

    // if the connection closes to the client, remove them
    // from the connections array.
    request.on('close', function () {
      removeConnection(response);
    });
  } else {
    // if the client doesn't accept event-stream mime type,
    // send them the regular index.html page - you could do
    // anything here, including sending the client an error.
    response.writeHead(302, { location: "/index.html" });
    response.end();
  }
}

// send the data (event type, id, message, etc)
response.write(data);

// if our response contains our custom xhr property, then...
if (response.hasOwnProperty('xhr')) {
  // clear any previous timers using the xhr prop as the value
  clearTimeout(response.xhr);

  // now set a timer for 1/4 second (abritrary number) that
  // then closes the connection and removes itself from the
  // connection array.
  // The delay is in place so that a burst of messages can 
  // go out on the same connection *before* it's closed.
  response.xhr = setTimeout(function () {
    response.end();
    removeConnection(response);
  }, 250);
}

Server-Sent Events originally appeared on HTML5 Doctor on January 24, 2012.

Return of the HTML5 clinic

We’re proud to tell you that (most of) the HTML5 Doctors will be attending @media 2011 and taking your questions. We’ve got our own desk (like last year) and we’ll be available between the conference talks. That way you can fill your head with lots of juicy information, and then trundle your way over to the handsome guys in the white jackets and ask your best HTML5 question (for which there will be a reward!^†).

† Actually, we’re feeling kind, so anyone that asks a question, flashes us a kind smile or buys us a pint will get an exclusive little gift from your friendly doctor.

@media

If you’re wondering what @media is, you’ve either been hiding under a rock or you’re new to the business. None the less, we’re more than glad to tell you about it.

Founded in 2005, @media is recognised as one of the world’s leading conferences for web professionals. They pride themselves on keeping up to date on the latest moves in the design and development world. That means HTML5 has a big presence in their program of hand-picked world-leading experts.

Just some of the subjects that folks are speaking about during the two day conference:

• Our very own Bruce Lawson, talking on native multimedia with HTML5
• Mike Mahemoff (Google’s UK badass) speaking about HTML5 offline for fun and performance
• Dave Bulmer with Rockstar graphics with HTML5 (yes, we did say rockstar graphics!)
• Nicole Sullivan on Performance of CSS3 & HTML5

Our special discount code

For those of you that don’t have a ticket to this excellent conference already, you might be thinking you’ve missed the early bird prices – fret not my dear friend, we have your back! We’ve managed to procure you a special discount code that will get you £100 off the current asking price. Just use the code HTML5DOCTOR and it’ll knock the price down for you: book it now.

If you’re coming along, drop us a comment below and we’ll see you there!

- Rich, Remy, Mike, Bruce & Jack, xxx

Get your HTML5 prescription filled at @media originally appeared on HTML5 Doctor on May 3, 2011.

This post will be an overview of the technologies available, how well they’re currently supported, and, where possible, live demos. I’m going to touch on the following technologies:

• XHR & XHR2 with CORS
• Web Messaging
• Web Sockets
• Server Sent Events
• Web Workers

Before I get on to the APIs, I want to outline a fairly common communication model that several of these APIs use.

A common communication event model

All event handlers (with the exception of XHR) receive an event object containing a data property. This property includes the data sent as part of the message.

The event model (again with the exception of XHR) is mostly based around onmessage and postMessage or send. For example:

// in the recipient code
recipient.onmessage = function (event) {
  console.log('received message: ' + event.data);
};

// from the sender code
recipient.postMessage('hi there'); // or recipient.send('hi there');

This is just a common model and isn’t the exactly the same among all these technologies. The two key similarities are that they use:

• a sending method (postMessage or send) on the recipient object, and
• an event handler that listens for the message event and receives an event object containing a data property.

Very importantly, most browsers only support sending strings from sender to recipient, so we often need to JSON stringify and parse if we want to send anything other than a string.

XHR & XHR2 with CORS

XHR can be both synchronous and asynchronous. XHR is the only API that (purposely) supports synchronous requests, meaning the execution of code will block until the callback fires.

There’s nothing particularly new about XHR, but in XHR2 we can handle uploads, and there’s a progress event to tell you how the upload or download is getting on.

The super shiny new toy in XHR2 is its support for Cross-Origin Resource Sharing (CORS). This means you can make an XHR request across domains, but only if the server you’re connecting to allows it.

The request is as you’d expect from XHR:

var client = new XMLHttpRequest();
client.onreadystatechange = function () {
  if (this.readyState == 4 && this.status == 200) {
    alert('The most awesome-est person to follow: ' + this.responseText);
  }
};
client.open('GET', '/no-cors');
client.send();

If our server responds with a CORS header, however, we can put our XHR responder on another server. So on the URL http://remysharp.com/demo/cors.php, I have the following PHP script:

<?php
header('Access-Control-Allow-Origin: *');
?>
@rem

This says that anyone can make an XHR request to this particular script. Now when I run the following code in a browser that supports XHR2, the cross domain request succeeds!

var client = new XMLHttpRequest();
client.onreadystatechange = function () {
  if (this.readyState == 4 && this.status == 200) {
    alert('The most awesome-est person to follow: ' + this.responseText);
  }
};
client.open('GET', 'http://remysharp.com/demo/cors.php');
client.send();

Here’s a live example of CORS. (You can also edit it here.)

Note that IE8 supports CORS, but not XHR2 (no surprise there then). You need to use their proprietary (booo!) XDomainRequest object. Nicholas C. Zakas has an excellent article explaining how to handle these differences.

XHR usage is pretty common already, but XHR2 with CORS is a winner over JSON-P, particularly as you have finer control over the request, can handle timeouts, and can handle errors correctly.

Support for XHR & XHR2 with CORS

• XHR support is pretty solid nowadays (even though IE6 uses ActiveXObject to get it going)
• XHR2 with CORS: Safari & MobileSafari, Firefox 3.5, Chrome and IE8 (via XDomainRequest)

postMessage

This API is older, but it’s very useful if you want to get around the XHR same-origin rules. If you have an <iframe> document that can accept onmessage events from your origin (i.e., your site), then you can communicate across domains (and origins).

For example, a page that accepts an onmessage event might contain code such as this:

window.onmessage = function (event) {
  if (event.origin == 'mytrustedsite.com') {
    alert('my trusted site said: ' + event.data);
  }
};

Now you can include an <iframe> that contains that code, and using the <iframe> DOM node, you can post to the <iframe>:

// where iframe is the actual iframe DOM node
iframe.contentWindow.postMessage("hello there", location.host);

This gives you the ability to send strings across two mutually trusted domains. (Remember that you can use JSON.stringify and JSON.parse to convert to an object to and from string format.)

Support for postMessage

• Chrome
• Safari
• Opera
• Firefox
• IE8

Here’s a demo using postMessage.

There’s also a project called EasyXDM, which adds cross domain messaging to IE6 and upwards (along with all the other browsers) through the library’s abstraction. Definitely worth a look if this is a route you need to take.

Web Sockets

It’s my opinion that Web Sockets replaces Comet. Comet is a way of hacking the browser to giving us real-time server messages. The Web Sockets API provides that natively.

Web Sockets are used to send messages to and from the server — i.e., a bi-directional socket. In contrast to other similar technologies, with Web Sockets, you can go across domains, and you’re not bound by the same-origin policy. This means you can host your normal “apps” server while another server is for streaming content. Or you could host your own pages and connect to a live Twitter stream if your users turn on Web Socket support.

You can only send messages once the socket is open (duh). The communication model looks like this:

var ws = new WebSocket('ws://somesite.com/updates');

ws.onmessage = function (event) {
  alert(event.data);
};

ws.onopen = function () {
  ws.send('yay! we connected!');
};

Once the socket is closed, you can’t reuse it. Similarly, there’s no explicit method for opening a socket. That just happens when you create the WebSocket object.

This API is extremely simple. I most often get asked, “What do you put on the server side?” I personally use Node, but you could use an Nginx server or something like Jetty. I’m no expert on the latter servers, but I can vouch that a Node-based server is very, very simple to get going. The live demo below also includes a link to the code that I used to run the server.

Check out this demo of Web Sockets.

Support for Web Sockets

• Chrome
• Safari & MobileSafari

There’s also an excellent Flash poly-fill called web-socket-js. Drop this into an application and it provides Web Sockets support as if it were native. I’ve used this on a few projects of my own, and it works very well.

In early December 2010, there was a security notice posted about Web Sockets, and both Firefox and Opera pulled it from their upcoming releases. Mozilla have said that they expect Web Sockets to be back in Firefox by version 4.0.1.

Server-Sent Events

The Server-Sent Events API is something that originated from Opera back in 2006 and is used for pushing events from the server to the client. Note that the client cannot send messages to the server through an EventSource (SSE) — it can only listen for messages.

This API uses the onmessage model. It’s constructed using the EventSource object and is limited by the same origin rules:

var es = new EventSource('/sse');
es.onopen = function () {
  console.log('opened stream');
};

es.onmessage = function (event) {
  console.log('new message: ' + event.data);
};

The SSE automatically connects when you create the object (similar to Web Sockets), and once open will trigger the onopen event.

Here’s a live demo of Server-Sent Events

Here’s how this is to work: when a new message is pushed from the server to the client, it triggers the onmessage callback.

The key to your server is ensuring it doesn't close the connection on the client - the browser. Most of the examples around the web are doing this: closing the connection which tells the API to switch in to polling mode (note that this is the exact problem I hit when I first published this article).

When the API is in polling mode, it's no more different from an XHR poll, and the onopen will continually fire.

Support for Server-Sent Events

• Opera 11
• Safari & MobileSafari
• Chrome

Web Workers

Web Workers are a way of creating a new thread of execution inside the browser. I’m including this because you still need to communicate with your Web Workers, and the method of communication is similar to some of those techniques discussed above. Do note, however, that this is not a method communicating from a client (browser) to a server. It’s more like there’s another browser window executing a particular block of JavaScript.

As an example of when to use a Web Worker, say you’re running a lot of JavaScript and the UI becomes unresponsive. The browser UI hangs because, in a way, it’s a “single-threaded application”. (Under the hood it isn’t really, but from a rendering and JavaScript perspective it is). This JavaScript task could be given to a Web Worker so that the UI can continue functioning.

It’s vital to understand that a Web Worker lives in a sand-boxed environment that doesn’t have access to things like the DOM. What’s more, you can only communicate with it using the onmessage and postMessage functions.

Our application can create and send messages to a worker using the following code:

var worker = new Worker('bigjob.js');
worker.onmessage = function (event) {
  alert('Message from worker: ' + event.data); // remember event.data is a string!
};

worker.postMessage('task=job1');

In the JavaScript file bigjob.js, we run some computationally intensive task and listen for messages in a way similar to what we’ve done in the previous examples. We can also post messages back to the invoking application:

this.onmessage = function (event) {
  var job = event.data;
  if (job == 'task=job1') {
    job1();
  } else if (job == 'task=job2') {
    job2();
  }
};

// just a pseudo example
function job1() {
  // do some big task
  while (working) {
    // continue task
    this.postMessage('job1 ' + amountComplete + '% complete');
  }
  this.postMessage('job1 100% complete');
}

There’s a lot more to Web Workers than just running a couple of small tasks, and no doubt we HTML5 Doctors will be posting a detailed article soon. This example just demonstrates how to communicate with Web Workers and how similar that is to the other technologies we’ve discussed here.

Support for Web Workers

• Chrome
• Safari
• Opera
• Firefox

A final word

Hopefully you agree that this is just the tip of the iceberg of communicating between client and server in HTML5. We’re no longer stuck with the same origin policy we had with vanilla Ajax. In fact, when you think about it, since IE8, we’ve actually had decent cross-domain messaging.

I’m personally most excited about Web Sockets and the support of CORS in services that have APIs, like Flickr, Twitter, and URL shorteners. What could you build with this?

Methods of communication originally appeared on HTML5 Doctor on January 18, 2011.

A Note about Web Directions @media

Founded in 2005, @media is recognised as one of the world’s leading conferences for web professionals. We pride ourselves on keeping up to date on the latest developments in the design and development world. That means HTML5 has a big presence in our program of hand-picked world-leading experts this year. Here’s a taste of some of the HTML5 related talks and workshops that are taking place:

• HTML5 Doctor Bruce Lawson gives the lowdown on HTML5 for web designers, covering new semantic markup features, the HTML5 video and audio elements, and much more
• Fellow clinician Remy Sharp gets out his scalpel and dissects what HTML5 has to offer for application developers. He’ll also be delivering a full-day workshop on the same topic
• Jeremy Keith delivers a full-day workshop on semantic markup featuring HTML5
• Jonathan Stark looks at how you can use web technologies including HTML5 to build native applications for platforms like Android, iPhone, and iPad
• Matt Biddulph, founder of Dopplr, looks at adding geolocation to your web applications

Plus much, much more! For a complete rundown on what’s going on, see the full @media schedule.

HTML5 Clinic

All of us at HTML5 Doctor are very excited to announce that there will also be a special HTML5 clinic as part of the @media Expo. Led by various HTML5 Doctors, we’ll help cure what ails you when it comes to HTML5. Full details of the clinic will be made available shortly. We’ll be sure to let you know first.

Discount Codes

We’ve managed to get you a great discount on both the workshops and conference attendance. All you have to do is use the discount code ‘HTML5Dr‘ when booking and you’ll be eligible for the following:

1. HTML5 Doctor Remy Sharp’s “HTML5 for Web App Developers” workshop for £275 (£50 off)
2. Jeremy Keith’s “Get Semantic with Microformats and HTML5″ for £275 (£50 off)
3. Conference attendance for £399 (before discount period ends [around May 7th])
4. Conference attendance for £449 (after discount period ends)

So be sure to get the best deal on tickets and book before May 7th! If you’re going, let us know by leaving a comment below. We hope to see you all there!

HTML5 Doctor at Web Directions @media originally appeared on HTML5 Doctor on April 29, 2010.

For your convenience, we’ve put together a list of events where we’ll be speaking and even the ones we’re simply attending. Read on for some of our upcoming HTML5 appearances.

We’ll continue to maintain this page with new listings, so check back often. Otherwise you might miss us!

Run an event? Get in touch!

If you organise an event or workshop and would like us to speak (or you’d just like to see us there), then we’d love to hear from you.

HTML5 Doctor Speaking and Training Appearances originally appeared on HTML5 Doctor on April 16, 2010.