The internet is one of the largest nets in the entire world. Here are some things that I like/find humorous/want others to see/what-have-you.

Server-Sent Events: They’s Niiice

Posted on May 24, 2012 at 5:50 pm

I first heard about Server-Sent Events a few months ago, though I didn’t have a chance to take ’em out for a test drive until this past week. I have to say, I’m impressed.

Server-Sent Events refers to a new-ish spec which allows a server to push data to the web browser, requiring only a few lines of native JavaScript on the client-side. This new interface drastically simplifies web applications which rely on periodic updates from a server-side application. For example, Mozilla provided this example of a “wall” built using Server-Sent Events. I wrote some sample code of my own to see just how hard it is to implement Server-Sent Events, and the answer is, it’s not.

The Server-Side

The Server-Sent Events spec is really just a new way of solving an old problem. For quite some time, developers have been building client-side applications that periodically refresh themselves with up-to-date information, the obvious example being sites like Facebook and Twitter. Historically, these applications have relied on long polling, where the JavaScript setTimeout method is used to repeatedly make AJAX requests to retrieve fresh data. The biggest change with Server-Sent Events is that the server is given control over this process, using a push rather than a pull. The client makes an HTTP request, and from there the server sends responses at intervals it defines. The benefit of this approach is that the client only makes a single HTTP request which stays open, rather than an ongoing series of requests which come with excess overhead.

As an example, I modified the photo API that I created for my earlier post on CORS to support Server-Sent Events. Here’s a look at the modified response from that API:

retry: 8000
data: { "kjonaas": {
   "photo": {
      "large": "",
      "small": "",
      "caption": "Riding his motorcycle at Auditorium Shores.",
      "date": "02/27/2010"

The first line defines the interval for pushing data to the client in milliseconds. The second is the data to be sent in the message, in this case formatted as json. While my example doesn’t, the response can also include an event, which as its name implies, allows the server to notify the client when an event occurs. An example would be a login or logout event.

The Client-Side

With the API above complete, I only needed to write a tiny bit of HTML and JavaScript to display a random photo of my son every 8 seconds. If you view source on, you’ll see the following JavaScript:

if(window.EventSource) {
   var source = new EventSource('' + 
   'random.php?format=json_sse&ts=' + new Date().getTime());
   source.addEventListener('message', function(e){
      var photo = JSON.parse(;
      document.getElementById('kjonaas').innerHTML = '<img src="' + 
      photo.large + 
      '" alt="" /><br />' + 
   }, false);

The crux of Server-Sent Events on the client-side is the EventSource constructor. As you can see, I simply bound an event listener to the message event that parses the data seen in the response above. Again, after the initial HTTP request is made by the client, it will stay open, and each time the server sends a new message, this function will be fired once more. Pretty cool!


While modern browsers such as Firefox, Chrome, Safari, and Opera support Server-Sent Events (and in many cases have for some time now), it’s worth noting that there are two kind of important browsers that don’t: Internet Explorer and Android. That shouldn’t be used as a reason not to implement Server-Sent Events, however! For these browsers, developers can just continue to use long polling.

What’s more disappointing to me is that it appears that currently Firefox is the only browser that supports Server-Sent Events via CORS, as I can think of plenty of interesting cross-domain applications of Server-Sent Events.

Another slightly annoying issue that’s going to have to be addressed by browser vendors as Server-Sent Events are more widely adopted is that one cannot directly view message data, because the client doesn’t seem to know how to render the text/event-stream Content-Type. This made troubleshooting issues I encountered with my API difficult, as neither Firebug nor the Chrome Net panel are capable of displaying the response.

Leave a Reply to noah.cooper Cancel reply

2 Responses to Server-Sent Events: They’s Niiice