Speaking as the principal developer for TogetherJS:
In the past we have opted not to work on IE support because we had limited resources, and because we wanted to focus on what we thought were the hard problems: how should the tool act, how do we communicate changes between browsers, how do we integrate with apps, etc. Supporting Internet Explorer was always something we knew we could do, it wasn't a hard problem, but it still required some effort. As such it didn't feel like it was advancing the project. It was never meant as any slight towards IE, just an expedient way to save some time.
Also, while we do browser sniffing, we only use that to put up a warning for IE users to alert them that it's not going to work well. This was pointed out on Twitter as though we were actively blocking browsers, in part I think a knee-jerk reaction to browser sniffing, but what we've done still seems to me like a reasonable and responsible thing to do – better to admit you don't support a browser than just expose people to a crappy experience.
Of course times change, and as TogetherJS has become a more mature tool it's probably time to revisit our Internet Explorer support. But on the other hand this isn't a commercial tool, so I'm not entirely sure what resources we as a team will be able to invest in Internet Explorer support. But it's also open source, and we would welcome contributions to fix this. We'll be working on a slightly more structured plan soon. It might not even be much work, I really don't know.
Thanks for this response. I think if we implement TogetherJS in our app we'd be doing somewhat-heavy IE testing so in that event we could perhaps send pull requests upstream for any bug fixes.
In the past we have opted not to work on IE support because we had limited resources, and because we wanted to focus on what we thought were the hard problems: how should the tool act, how do we communicate changes between browsers, how do we integrate with apps, etc. Supporting Internet Explorer was always something we knew we could do, it wasn't a hard problem, but it still required some effort. As such it didn't feel like it was advancing the project. It was never meant as any slight towards IE, just an expedient way to save some time.
Also, while we do browser sniffing, we only use that to put up a warning for IE users to alert them that it's not going to work well. This was pointed out on Twitter as though we were actively blocking browsers, in part I think a knee-jerk reaction to browser sniffing, but what we've done still seems to me like a reasonable and responsible thing to do – better to admit you don't support a browser than just expose people to a crappy experience.
Of course times change, and as TogetherJS has become a more mature tool it's probably time to revisit our Internet Explorer support. But on the other hand this isn't a commercial tool, so I'm not entirely sure what resources we as a team will be able to invest in Internet Explorer support. But it's also open source, and we would welcome contributions to fix this. We'll be working on a slightly more structured plan soon. It might not even be much work, I really don't know.
Here's the bug to watch: https://github.com/mozilla/togetherjs/issues/867