While I agree that XMPP is not the future for app-to-app communication, I do so for a slightly different reasons.
> XML is unnecessarily complex for this kind of usecase
XMPP is too complex, but the XML stuff is really the smallest issue, compared with other complexities in the protocol. For example, every client that successfully connected to an XMPP server must first send a "<presence>" message. Otherwise, it won't receive any messages despite their successful connection. And there are more such surprises in XMPP. Good luck in understanding which "devices" (#xxxx) of the same Jabber ID will receive a message targeted at that ID.
It's really annoying and discouraging to debug that kind of issues - especially since these aren't bugs. These work as specified, but the specifications were obviously designed with direct human chatting or direct human collaboration in mind, programs being an afterthought.
> The correct technology is JSON-over-WebSockets
Not really. Whenever I saw someone trying this "in the wild", I see them quickly switching to HTTP long-polling. (Not to be confused with polling! We are still talking about instant push notifications with very low network overhead.)
For example, there are some libraries that used to provide wrappers around WebSockets, which switched to HTTP long-polling as fallback for old browsers. Nowadays, it seems they use long-polling by default, even though browser support becomes better and better.
Don't underestimate the role of firewalls and HTTP proxies! Many firewalls are aggressive configured, and many companies have forced HTTP proxies in place.
That is a browser issue, and does not exist in native clients. If we're talking about XML-stream-over-sockets, then comparing it to browsers makes no sense (because they can't do that!), and thus long-polling and JSON-over-HTTP become irrelevant.
EDIT: Hmm, did you edit your post? I don't recall the first part being there... anyhow:
> XMPP is too complex, but the XML stuff is really the smallest issue, compared with other complexities in the protocol.
That is one factor, but the protocol complexities often seem to derive from the question 'how do we represent this in XML?', and that's an issue.
Another problem is the jargon - the MUC specification is utterly incomprehensible, because the terms it uses for things are so wildly different from how they are used everywhere else, that building a mental model is really hard. I've seen this issue in other XEPs as well.
> For example, every client that successfully connected to an XMPP server must first send a "<presence>" message. Otherwise, it won't receive any messages despite their successful connection.
That statement is wrong. Sending an initial presence merely indicates your availability to entities subscribed to your presence. Not sending the initial presence does not prevent you from receiving message stanzas.
Addendum: As Zash pointed out[1], this is documented behavior for offline messages, i.e. messages send while the user was offline. Those are only send if the user announced availability via a presence or if XEP-13: Flexible Offline Message Retrieval is used. This is to prevent storms of offline messages when the client (re-)connects.
But it's certainly not true that you "won't receive any message despite ... successful connection".
Indeed, my description was rough and from memories a few year ago. But I believe it still demonstrates the point I was trying to illustrate:
There is unneccessary complex behaviour in XMPP that you must write extra code in your client for. Otherwise it will work mostly, but not always and not reliably.
Really? The old Google Talk service used to do this, but I didn't think ejabberd did. There's a bunch of non-IM use-cases which need presence-less messaging.
+1 that JSON-over-WS is not a panacea. Long-polling is inelegant but is pretty efficient with HTTP/2.0, and trivially degrades on older HTTP stacks (e.g. in embedded devices) which don't know anything about WS.
Dave Cridland's wiki page makes some good points, but predictably it paints a very black and white view of the world. Some contentious points are:
1. Myth One: XMPP is XML, so it's too slow.
...there are obviously faster encodings than XML out there (e.g. CBOR), so this feels like a slightly specious point to argue. Sure the difference isn't that important on the clientside (perhaps more of an issue for squeezing every last drop out of a server), but why not acknowledge it?
2. Myth Two: The baseline is minimal, therefore XMPP is useless.
I'm not sure anyone claims XMPP is useless just because its baseline is minimal. The issue is instead the fragmentation caused by lack of interoperability profiles for all the different extensions. Statistically, if I pick an arbitrary XMPP client and an arbitrary XMPP server, the overlap of supported XEPs is unlikely to provide a good modern comms experience. If it was a "bug" for your client or server not to implement a given critical XEP, then fragmentation would be less of an issue.
3. Myth Three: It's too bandwidth-inefficient for mobile.
Just because you can successfully talk XMPP over a 9600bps link with 30s of latency doesn't mean that the default transport is bandwidth efficient(!) That said, the XEPs for constrained networks are a better justification.
4. Myth Four: XMPP is unreliable without a bunch of extensions.
As Dave repeatedly says, XMPP is a NAK protocol - by default messages are not acknowledged, so whenever a TCP stream drops you have no way of knowing whether the last messages in the stream got through or not. This is to me the definition of an unreliable delivery mechanism, and you have to mitigate it with extensions (XEP-198). I'm still not sure how this one's a myth...
5. Myth Five : XMPP is unsuited to the web.
The hypothesis of "XMPP is unsuited to the web because angle brackets and stuff" isn't exactly well articulated here. I think the actual complaint here is "why bother putting an XMPP stack in your browser when you already have an HTTP stack there"? What value do the remnants of XMPP's transport semantics have when you already have HTTP as a transport? I agree that Stanza.io & XMPP-FTW make this less clear cut, however.
For what it's worth, the FAQ entry that triggered this wiki page can be found at http://matrix.org/blog/faq/ (What’s the difference between Matrix and XMPP?).
> XML is unnecessarily complex for this kind of usecase
XMPP is too complex, but the XML stuff is really the smallest issue, compared with other complexities in the protocol. For example, every client that successfully connected to an XMPP server must first send a "<presence>" message. Otherwise, it won't receive any messages despite their successful connection. And there are more such surprises in XMPP. Good luck in understanding which "devices" (#xxxx) of the same Jabber ID will receive a message targeted at that ID.
It's really annoying and discouraging to debug that kind of issues - especially since these aren't bugs. These work as specified, but the specifications were obviously designed with direct human chatting or direct human collaboration in mind, programs being an afterthought.
> The correct technology is JSON-over-WebSockets
Not really. Whenever I saw someone trying this "in the wild", I see them quickly switching to HTTP long-polling. (Not to be confused with polling! We are still talking about instant push notifications with very low network overhead.)
For example, there are some libraries that used to provide wrappers around WebSockets, which switched to HTTP long-polling as fallback for old browsers. Nowadays, it seems they use long-polling by default, even though browser support becomes better and better.
Don't underestimate the role of firewalls and HTTP proxies! Many firewalls are aggressive configured, and many companies have forced HTTP proxies in place.