You've got this all backwards.

Something being suitable for use on the sites is the first (not last) step in proving it's viable for inclusion in the API.

The difference is, if something isn't working out on the sites we can immediately change it. Websockets not working out? Go to long polling. Long poling also garbage? Just plain jane ajax'ing then.

Basically, what matters on the sites is the user experience not the technology used to create it.

The API, on the other hand, has to keep to a rigid contract. If websockets proved to be unacceptable we wouldn't have a recourse beyond breaking every single consumer. If in a few more months websockets are still chugging along, we'll start thinking about using them in the API.

As an aside, websockets aren't nearly as stable as you think on the sites at the moment. We've disabled them multiple times in the last few weeks, and have major caveats around how they're used (primarily, they're push only; you can't communicate with the server).

You've got this all backwards.

Something being suitable for use on the sites is the first (not last) step in proving it's viable for inclusion in the API.

The difference is, if something isn't working out on the sites we can immediately change it. Websockets not working out? Go to long polling. Long polling also garbage? Just plain jane ajax'ing then.

Basically, what matters on the sites is the user experience not the technology used to create it.

The API, on the other hand, has to keep to a rigid contract. If websockets proved to be unacceptable we wouldn't have a recourse beyond breaking every single consumer. If in a few more months websockets are still chugging along, we'll start thinking about using them in the API.

As an aside, websockets aren't nearly as stable as you think on the sites at the moment. We've disabled them multiple times in the last few weeks, and have major caveats around how they're used (primarily, they're push only; you can't communicate with the server).