Its a shame more people don't realize what a gold mine of a piece of technology it is.
You're right that neither SC not Deepstream support long polling fallbacks but there are some very good architectural reasons for this. Both SC and Deepstream used to support HTTP long polling fallbacks via engine.io in the past but both projects independently decided to stop doing it after years of experimentation and feedback.
Now that WebSockets are well supported in all major web browsers and HTTPS has become even more prevalent (so corporate proxies are no longer a problem), the extra load balancing complexity, performance costs and the DoS vulnerabilities of long polling are no longer worth it.
Also, for these proxies to work, the company has to have access to the user's machine to install their own root CA certificates onto it; so generally, this issue is limited to corporate workstations and not BYO mobile devices and personal devices.
It's only a big problem if you want to support users from a specific company which happens to be a major customer (like a corporate SaaS solution); but if that particular company is such a big user of your product then they can always change their proxy policy to allow WebSockets from your domain.
I think that there are few enough of these companies that they should be the ones to adapt to new technology and not the other way around. It's important for open source projects and companies to set positive standards and not always bend to the will of corporations; especially when it comes to ethically-questionable practices.
You can still offer a REST API without real-time features for those users. The cost of long-polling is that bad. It's very easy to DDoS.
I can definitely appreciate the additional complexity of supporting the fallback. I imagine that elixir's OTP and STM functionality lowers the bar for handling the extra state management across multiple nodes.
Not that that takes anything away from your argument, but given that this topic is about Firebase, readers could get the impression that it offers the same.
That said, I like Phoenix Channels too, and the long polling support is a must-have for us. The "very good architectural reasons" for not doing this, as quoted by @jondubois in a sister comment, are nice, but if that means that 10% of our audience can't use our product then that's a show stopper. I love that Phoenix takes these cases seriously.
That said, Phoenix Channels are a mess when it comes to documentation and terminology. It's built on only two terms, "socket" and "channel", both of which mean 2 to 3 different but related things.
(background: at https://talkjs.com we recently moved our realtime stuff from Firebase to Phoenix Channels)
https://ashleyconnor.co.uk/2016/03/06/deploying-a-phoenix-ap...