Next week I will be presenting at Scala Days. In my talk I will discuss how to build reactive applications with two-way (near) real-time communication, using the combination of Server Sent Events to provide clients with updates and REST calls for the backchannel. You may already be familiar with two examples of this architecture: BirdWatch and sse-chat. I am now thinking about potential questions in the Q&A session after the talk. One potential issue that came to mind almost immediately was the support for Internet Explorer. Out of the box, IE does not support Server Sent Events. Personally, I do not care very much about IE support. I had not used it in years before I started researching for this article, and only a low single-digit percentage of visitors on my blog use IE. But I understand this can be a showstopper. So if you don’t care about IE support at all, you really don’t need to read any further. Otherwise, bear with me.
- The global EventSource object is only ever replaced if it doesn’t exist. That way I don’t have the burden of having to check if this implementation works with all currently available browser versions (and those to come). Rather, the global EventSource object from the polyfill is only created in Internet Explorer.
- The check for the “correct” ContentType is removed. Out of the box it did not work with Play Framework, but without this check it does. I didn’t care much about changing the ContentType on the server side just to make the polyfill happy.
Let’s have a quick look at the code modifications. They are really short.
1 2 3 4 5 6
The block above ensures that the anonymous function creating / replacing the global EventSource object is really only executed when there is no such global object. This is done by wrapping the anonymous function creating the EventSource object in another anonymous function that does the check. The global EventSource is then created below:
The only other thing to note is that a check for the expected ContentType was disabled as it was incompatible with the out-of-the box behavior of Play Framework’s EventSource implementation:
1 2 3 4
Then finally all there is left to do is load this modified polyfill in the application, like this:
Great. Much better than having to answer “sorry, IE is not supported at all”. Blaming Microsoft alone is not going to help much when your client demands just this particular support. Now if you want to use this architecture for a reactive application and your pointy-haired boss comes along, demanding support for IE, you can put a smile on your face.
I am happy to have this potential showstopper out of the way. I’ve been meaning to address this problem for a while, I just dreaded the logistics of setting up a testing environment for IE, and that part was about as annoying as expected. I had to dig out an old Windows 7 image for VMWare Fusion, copy the 40GB over rather slow Wi-Fi and then do all the due updates, with multiple restarts of the VM, of course. Oh how I have missed Windows. I had almost forgotten. How can it take hours to load the updates that make me eligible for IE 10 alone? Anyhow, that’s about as much exposure to Internet Explorer as I can deal with for the moment. With Internet 10 and 11, the core functionality with the Server Sent Events works fine now.
The Rickshaw time series chart on the upper right in BirdWatch does not seem to work in IE, but that’s not part of the proof that the proposed architecture works with newer versions of IE. I do not plan on spending any more time making IE 8 and 9 work, but in theory it sounds like that would be possible, at least according to the documentation of Yaffle’s polyfill. Please feel free to fix this in case you know a solution. There’s a fork of the polyfill that would happily accept pull requests. Thank you.
Okay, until next time, I hope to see you at Scala Days. Say hi when you see me, please. Matthias