I think the biggest reason for many modern chat services to disregard XMPP is, because they fear that most advanced users might resort to their Adiums & Pidgins and wont use their web-services or Apps at all, resulting in half of the customers not experiencing the UX or unique features and therefore the value.
We had a long discussion in the beginning of the project and decided to make our architecture XMPP-friendly, but release it later in the future, as we need our early adopters to use the system.
So the answer to XMPP is "Yes, but after we gathered enough feedback"
most advanced users might resort to their Adiums & Pidgins and wont use their web-services or Apps at all
Oh, noes, that would be terrible. I cannot explain in words how much I loathe the Slack app and by extension how much I loathe their "UX experience and unique features."
Since my company just recently left HipChat for Slack, I think the odds of switching again this year are pretty slim, so I haven't evaluated your app. I just want to ensure that you have considered that a non-trivial portion of the engineering group of a company may want to resort to their Adiums.
I think some of it is "worse than what": we were on HipChat, and it was not very nice, but at least they made an actual OS X application and allowed one to customize its behavior on my machine. The Slack "app" is just a packaged version of WebKit and has almost zero customizations. Worse of which is that there isn't a per-channel setting to hide images by default, since I've had no luck getting folks to stop posting animated gifs into the general channel. I'm not at work right now in order to speak to the specifics, but the Slack app doesn't handle that situation correctly at all.
And the notification is merely a red dot. Oh, you only want the red dot if you're at-mentioned or someone posts in your team's channel? Too bad.
If you just distribute your site's webpage as an app, you're phoning it in. And that is why I want a chat company to use XMPP so that I can use Adium to manage my interaction (or lack of it) with the chat service.
I'm glad you like Slack. I'm sure they're going to do well, given how many folks sing their praises.
I think your UX and other unique features should be so compelling that customers want to use your system (over than Adium or Pidgin).
Think GMail for example. It's got full IMAP and POP3 support, and people who want to use a mail client are free to do so. If they do (and I assume many people do), then Google doesn't get to serve ads to them. But Google still gives you the freedom to choose. And they've succeeded in alluring even the nerdiest of people to their web app.
In short, let your users decide. Make your UI so awesome that they want to use it. Having XMPP support will actually draw many customers to your service, since it's something that not all competing services offer.
You and others made some very compelling points in regards of XMPP.
We learned a lot from this discussion and I'll soon write a post about the takeaways we got from this HN-Thread at our blog - http://blog.chatgrape.com/.
I get that you want to showcase your features, but speaking for myself at least, choosing not to support XMPP means you don't even make the list of possible alternatives to what we have now.
Making that promise is nice (if we can agree to call that a promise), but I have to make a decision based on what you provide now, not what you promise to provide in the future.
I think the biggest reason for many modern chat services to disregard XMPP is, because they fear that most advanced users might resort to their Adiums & Pidgins and wont use their web-services or Apps at all, resulting in half of the customers not experiencing the UX or unique features and therefore the value.
We had a long discussion in the beginning of the project and decided to make our architecture XMPP-friendly, but release it later in the future, as we need our early adopters to use the system.
So the answer to XMPP is "Yes, but after we gathered enough feedback"