@Isaac: Thank you, as an OpenGL beginner I stumbled about this one before

“You’ve probably noticed: I think we should be getting behind WebSockets ”

I agree. And I think we should be getting behind EventSource too, since they both have their pros and cons in different scenarios! If we can find scenarios where one is preferable over the other, we can make better decisions.

“The benefits of the realtime web are really about interaction and engagement. To achieve this you need two-way communication and that’s what WebSockets offer. For that reason I wouldn’t say EventSource is an alternative to WebSockets. For me, they are only useful for connecting and pushing data. That makes the use cases limited.”

We have two-way communication with EventSource+XMLHttpRequest, so the scenarios that are left IMO is the scenarios when you have lots of data client-to-server and it needs to “real” realtime. (i.e. games, some collaboration tools and perhaps trading apps). Can you think of more scenarios?

“One of the benefits of WebSockets is the lower latency. You connect, upgrade the connection from HTTP and from there messages are small with very little overhead.”

Yes, it’s a lower latency per message client-to-server, but not the other way = good for “real” realtime client-to-server.

“If you do open and close an connection with EventSource then you are introducing an overhead (HTTP headers) with those connections.”

If the event server is keeping the connection open, the number of HTTP requests will be exactly the same as in WebSockets.

To summarize: As I see it, if the scenario is that you need “real” realtime for client-to-server communication, then go for WebSockets. Otherwise, EventSource/SSE is a technology you should consider evaluating.

We haven’t encountered the problem with the circle in our project, but there we are still using version 3.6. It seems to me then that there is a bug in the 3.7 version that’s neither in 3.6 nor 3.8.

var infoWindowVisible = function () {
var currentlyVisible = false;

return function (visible) {
if (visible !== undefined) {
currentlyVisible = visible;
}

return currentlyVisible;
};
};

… you can then call infoWindowVisible to get a function to track the InfoWindow state for each marker. If you call it at the beginning of addInfoWindowListeners like this:

var infoWindowVisible = infoWindowVisible();

… you don’t need to change anything else in addInfoWindowListeners.

There might be more you’ll need to change to get your use case to work. Good luck!

[MainThreadForwardProxy proxyWithTarget:self retainArguments:YES] returns an object that has -forwardInvocation: and -methodSignatureForSelector:. Its -methodSignatureForSelector: simply asks its target for the signature. Its -forwardInvocation doesn’t have to do any varargs monkey business because it already gets the properly set up invocation.

* http://caniuse.com/#search=eventsource
* http://caniuse.com/#search=websockets

The benefits of the realtime web are really about interaction and engagement. To achieve this you need two-way communication and that’s what WebSockets offer. For that reason I wouldn’t say EventSource is an alternative to WebSockets. For me, they are only useful for connecting and pushing data. That makes the use cases limited.

One of the benefits of WebSockets is the lower latency. You connect, upgrade the connection from HTTP and from there messages are small with very little overhead. If you do open and close an connection with EventSource then you are introducing an overhead (HTTP headers) with those connections.

You’ve probably noticed: I think we should be getting behind WebSockets Even the inventor of ‘Comet’ thinks that’s the case: http://www.leggetter.co.uk/2012/04/22/websockets-realise-comet-theyre-not-an-alternative.html#comment-518850026

I do have to admit, however, that with the EventSource Polyfill (https://github.com/remy/polyfills/blob/master/EventSource.js) you probably get very close to 100% browser coverage. Whereas with the WebSockets one you are probably just high 90′s.

Anyway, very informative post and very nice WebSequenceDiagrams – they are super-useful.

System.Runtime.Serialization.Json;

Implicit data templates isn’t a big problem. Template selectors are still applicable, although not as elegant as implicit data templates.

When it comes to custom markup extension< there are no easy answers, sometimes it’s possible to use type converters but more often you have to rethink how your view models work.

Hopefully the functionality will reach WinRT XAML but for now rework for this has to be done if you are trying to port a SL5 or WPF project. And I would suggest reworking most of the views anyway as the design and interaction in Metro design is quite different from what you normally do in WPF and Silverlight.

I’ve tried using MVVMLight in the past, but it was too simplistic for my needs.

I reaalllyy don’t want to roll my own framework but it’s starting to look like I may need to go that route.

Anyway, thanks for the feedback and article series.

The circle around the marker works in Chrome and Firefox, but not in Safari (on a Mac). Interesting!