“WebSockets or Comet”

I’ve been thinking about writing about this frequently used statement for a while, and I’ve seen a few comments and discussions previously about this e.g. from Martin Tyler of Caplin Systems and Peter Lubbers of Kaazing in a post on InfoQ).

Martin’s point of view is:

One thing I don’t understand is your stance on Comet. You seem to want to distance Kaazing from Comet, despite the fact that your WebSocket emulation is surely Comet. More than this though, WebSocket itself is also Comet since Comet is just a paradigm, not a any specific transport mechanism.

Peter’s opinion is:

Comet is a programming model that allows a web server to push data to a browser. This is often achieved through a long-held HTTP request, but there really is no standard or specification for Comet; it is just an umbrella term for all the different ways that can be used to achieve this.

WebSocket, on the other hand, is a well-defined API and protocol that allows for full-duplex, bidirectional communication (not just server push).

Can you really say WebSockets is an alternative to Comet when Comet servers use WebSockets?

My current thinking is the same as Martin’s (I did used to work with Martin). It is that:

Comet is a paradigm, not only for server push but also for bi-directional communication.

The need to do this with a web browser resulted in WebSockets – something which natively supported this in a way that HTTP did not. So, we have Comet to thank for WebSockets.

The Wikipedia Comet entry states:

Comet is a web application model in which a long-held HTTP request allows a web server to push data to a browser, without the browser explicitly requesting it. Comet is an umbrella term, encompassing multiple techniques for achieving this interaction.

Alex Russell’s original Comet blog post states:

Fundamentally, they all use long-lived HTTP connections to reduce the latency with which messages are passed to the server.

The architecture relies on a view of data which is event driven on both sides of the HTTP connection.

All very HTTP related. But the second quote interestingly says “event driven on both sides”. This bi-directional communication, backed up by the diagram from the web post (see below), seems to have been lost in the wikipedia entry.

What I’m suggesting is that Comet is a paradigm for realtime bi-directional communication between a server and a client. Initially it used long-lived HTTP connections in addition to a second short-lived connection for command requests (e.g. subscribe) because it was the only solution. Comet servers now use WebSockets because they are now available, are better than the HTTP-based alternatives and help Comet (the paradigm) be achieved and finally truly realised in a standardised way.

I’m suggesting that HTTP Long-Polling or HTTP-Streaming (all using XMLHttpRequest, Script tag polling, IFRAMES, ActiveX objects) and WebSockets are transfer technologies (Martin used the term “transfer mechanism”) that make the Comet paradigm possible.

I’m suggesting that saying “Comet or WebSockets” is an invalid statement and that the Wikipedia article is incorrect and that this diagram better reflects the relationship between WebSockets and Comet:

I’m prepared to be wrong by being convinced otherwise. But I don’t think I am or will. Interested in hearing your opinions.

Note: I originally posted the core text to this as a comment on a blog post “Websockets or Comet or Both? What’s supported in the Java EE land”

Related posts:

1. What came before WebSockets?
2. Why Comet is key to the Truly Real-Time Web
3. Q&A: Are WebSockets ready for commercial use?

Ideas & Prototypes

Simple SMS Education

Using SMS and mobile to help deliver interactive, remote and continuous teaching – Daniel Probert.

See the code in github

TransAfrik

A number of ideas around crowd sourcing all sorts of information with an initial focus on travel; traffic, route planning and more.

Chircle

A way of making a single charity payment and being able to distribute parts of that payment to multiple chosen charities – Stef Lewandowski

Visit Chircle.com and signup

De-code Africa

Build a fun way of discovering interesting facts and stats about Africa, and the countries within the content, and compare the information against other non-African countries.

See the app in action

The Pitch

At the end of the second day each idea was given three minutes to pitch, and if possible demo. And today (Monday, March 19) they will be pitching to a group of 100 people including numerous company CEOs, at least two country presidents and a former Prime Minister at The Times CEO Summit Africa (RSS news feed) – a real opportunity to potentially get funding and affect change.

The Impact of Realtime

Public speaking is quite new to me. In the past couple of years I’ve spoken at just a handful of events. However, over the past few weeks I’ve give more talks than ever about Realtime web technologies, including a lightening talk yesterday at CodeAfrica.

The more talks and workshops I give the more I realise that no amount of speaking will beat actually demonstrating a realtime web technology. But not only demonstrating, also using the technology to make the audience part of the presentation, and make it an interactive presentation which encourages discussion and stimulates ideas.

I saw this again yesterday when Daniel Probert, who lead the Simple SMS Education team which I was part of, demoed the prototype. As part of his three minute pitch Daniel used the prototype web app to send a question via SMS (thanks to Twilio to a number of people in the room. They then reply to that SMS with the answer to the question. These answers are instantly displayed within the prototype application (thanks to Twilio WebHooks and Pusher). This was described by one of the feedback panel as “A killer demonstration”.

The ability to instantly demonstrate interaction between multiple people using SMS and realtime web technologies has a real WOW-factor. I’ve used this sort of technology for over 10 years and I’m still excited and wowed by it!

Final Thoughts & Thanks

CodeAfrica was organised and ran by Federica Cocco, Peter MacRobert and Tom Whitwell and Xen Lategan so they deserve a lot of credit for a great event and bringing so many interesting and creative people together.

It was also great to work with Anibe Agamah, Daniel Probert, Jianfeng Tian, Ilias Bartolini, Andrei Simion and Simona Ciocoiu.

With my core interest in technologies being realtime technologies I thought that the lack of Internet infrastructure (mobile data networks) in some areas of Africa was going to mean that I wouldn’t be able to use this technology over the weekend. However, it was used (and will be used today in Daniel’s pitch) to add real impact when demonstrating how technology can really make a difference.

Related posts:

1. Hosted realtime services – making the realtime web more accessible
2. Edinburgh Techmeetup, Web Browsers & the Realtime Web
3. Realtime Commenting blog post on Smashing Magazine

jQuery is a funny thing; it’s made JavaScript coding easy for advanced developers and accessible to web designers, and you could even say that the web designer role has very much changed because of it. It’s made web interfaces much richer and interactive. But, it’s also made us lazy because it’s so easy to use. It’s time to take a step back and start thinking about best practices. And sometimes that might mean not using jQuery.

I was really pleased to hear Christian Heilmann‘s talk on moving back to using native methods, rather than always using jQuery (you can read Christian’s write-up and get see his slides here). His reasons for this were:

• To encourage education about native browser functionality
• Native browser methods can perform better

This latter point is of particular interest to me. Whilst at Caplin Systems I was part of a development team where performance was critical. We were (they still are) building realtime web libraries and UIs which need to deal with both high frequency of data updates and large data sets displayed within the UI. I met up with Rich Chamberlain, Caplin’s dev manager, about a month ago and he reminded me of this. So, I set about comparing document.getElementById('someId') with $('#someId') and unsurprisingly the native method was by far superior.

For the results of this, and to test for yourself, see Considerations when updating the DOM to display realtime data.

What was surprising was just how much better document.getElementById is. You would assume (I haven’t looked at the source) that within the $ function that the selector would simply be checked:

$ = function(selector) {
  if( isIdSelector(selector) ) {
    var el = document.getElementById(selector);
    return warpInJQueryStuff(el); // el could be null
  }
  // else …
};

Ok, it’s probably nothing like this. But you get the idea. So, what is it that makes using jQuery comparatively so expensive? My guess is that it’s the warpInJQueryStuff. One of the parts of jQuery that makes it so powerful (all those functions you can call after selecting elements, and the chaining functionality e.g.

$('.something')
.doSomething()
.doSomethingElse()
.soOn();

The same goes when the selector isn’t just an id attribute selector i.e. a more advance CSS query.

$ = function(selector) {
  if( isIdSelector(selector) ) {
    //...
  }
  else if( isQuerySelector(selector) ) {
    var els = document.querySelector(selector); //**TODO: check**
    return wrapInjQueryStuff(els);
  }
  // else …
};

The jQuery library shoots itself in the foot a little bit here because they’ve added non-CSS selectors (I can’t find an example right now but a google suggests this is correct). However, this isn’t anything that a RegExp couldn’t test for and if the jQuery-specific selectors aren’t found then the native function can be used. Again, maybe it’s the wrapInjQueryStuff that’s the problem?

Anyway, the point is: don’t always use jQuery. As with anything, consider what you are trying to achieve and if performance matters, or you just want to learn, use the native methods instead. But remember to check for browser support.

If performance matters and you find this type of thing interesting then Doug Neiner’s talk on Contextual jQuery will probably interest you too.

Related posts:

1. Drag Drop bug in JQuery UI 1.5.3
2. Considerations when updating the DOM to display realtime data
3. Looking for a C# (ASP.NET MVC), jQuery & Real-Time Web Contractor

To demonstrate this, and show the considerations I’ve written a few small helper functions which can be called a number of times from tests and for each test I’ll time how long it takes to update the DOM a certain number of times.

For many web developers a script tag referencing in the jQuery library is one of the first elements to be added to any web page – it’s even in some web framework templates by default. So, a good first test is to time how long it takes for jQuery to update an element a number of times.

Now that we’ve defined one way of updating the DOM let’s add a way of caching a reference to the jQuery object that we create with the jQuery(selector) call. So, instead of having to make that call each time we can just access the object from a cache. This means that a new jQuery object doesn’t need to be created for every update.

jQuery uses CSS selectors to find elements so rather than going directly to single elements using id attributes let’s also define a test that uses a nested selector: div.top div.middle div.bottom p.update-me.

Finally, as a comparison let’s define functions which update the DOM by directly using the native document.getElementById and document.querySelector native browser functions, and both of these again using the caching technique we used earlier.

If we execute each of these methods so that they are called 500 times to update the DOM and repeat that 10 times we see results as shown in the following graph.

And if we take each of the results and average them out we see the following:

Conclusion

• If you are sending a reasonable number of updates, and you are going to be updated the UI a lot, that you should be using document.getElementById to access and update the DOM.
• If you want to use jQuery and the DOM structure isn’t going to update all that often then the caching references to jQuery objects is an efficient mechanism.
• If you are are using CSS queries then the native document.querySelector performs better than jQuery. In both cases the complexity of the query is undoubtedly going to impact the performance.
• Caching lookups of document.querySelector is a good idea since it improves performance.
• Unsurprisingly direct id attributes lookups are fastest of all.
• document.getElementById is the fastest way of accessing the DOM and caching lookups doesn’t make a big difference.

Related posts:

1. jQuery UK 2012 Event – don’t always use jQuery
2. Hosted realtime services – making the realtime web more accessible
3. Edinburgh Techmeetup, Web Browsers & the Realtime Web

Here’s a direct link to the “Web Browsers & the Realtime Web the past, present & future” slides.

Does WebSockets provide support for common use cases? Does it natively support Pub/Sub?

• var ws = new WebSocket(url) – connect
• ws.onopen = function() {}; – connected
• ws.onmessage = function(ev) {}; – some data has arrived
• ws.send({"some":"data"}); – send some data to the server
• ws.onclose = function() {}; – the connection has closed
• ws.close(); – close the connection

How do people on shared hosting use this technology?

Do WebSockets have problems with proxies and firewalls?

Where does SPDY fit into the Realtime Web?

Related posts:

1. Hosted realtime services – making the realtime web more accessible
2. Realtime Commenting blog post on Smashing Magazine
3. Code Africa & the Impact of Realtime

Realtime Web Technology Accessibility

Web Browser Wars

Cloud Hosted Services

Better self hosted solutions

WebSockets

Hosted realtime services

Where next?

• If you found this interesting you might find my Realtime Web Technology Guide/List of interest. If you know of any technologies that I’ve missed, please get in touch.
• Why not take a look at Pusher and the Pusher Blog

Related posts:

1. Edinburgh Techmeetup, Web Browsers & the Realtime Web
2. Code Africa & the Impact of Realtime
3. Realtime Commenting blog post on Smashing Magazine