I wrote that code, there were some reasons why we did it that way. First, before the 2.0 release, we ran several experiments with the connection strategy to fig

I wrote that code, there were some reasons why we did it that way. First, before the 2.0 release, we ran several experiments with the connection strategy to figure out the fastest way for the clients to connect to Pusher. We haven't had much experience with HTTP fallbacks, so it was important for us to make the learning process easier. This DSL helped a little bit. The main reason was that we were thinking about helping clients with server-supplied connection strategies. We could gather some metrics and tell the client in advance that, for example, WebSockets won't work due to some network issues. We also thought it could be useful for orchestrating migrations and working around potential load balancing issues. Injecting JavaScript was out of question, so I wrote this JSON DSL for connection strategies. We haven't done that and it's probably never going to happen. The Internet has moved on, we dropped support for some ancient browsers, connectivity has improved and we haven't really felt a need for that feature, to be honest. I agree that at the moment it's unnecessary.