This looks great but it seems they have no plans to support Internet Explorer (https://togetherjs.com/docs/#browser-support). That's a shame because most of our users who need this level of support all use IE :/
Haha, I'm not really sure what you mean. Yesterday I didn't know TogetherJS was ready to use, and yesterday I didn't know of Mozilla's plan to not support IE.
How could anyone be bothered by something before they know about it?
Today, IE users are not using TogetherJS. And if TogetherJS doesn't get it's act together they won't be using it tomorrow either. I have four browsers installed on my computer and everything I develop has to work on all four; one of them happens to be IE 10.
"We do try to throw up appropriate error messages when a browser lacks the necessary support. (WebRTC isn’t required to use TogetherJS, only to use audio chat, so the error message there comes up if you try to activate that function without WebRTC.)"
So, the issue is not specifically WebRTC support here.
Who cares. It's IE which needs to catch up to the standards Mozilla and Google are implementing. It's not like Windows users will be left out in the dark, they can always install Firefox.
Tell your users to use a real browser, or write a letter to Microsoft telling them to get with the times...
Even the University I attend doesn't support IE with their web-apps. They support Firefox...
Exactly. Note that Mozilla isn't being paid for this tool. It's open source though. So those who require IE support are welcome to pay someone to or add it themselves.
Everyone is happy, except those who want goodies for free. ;)
Except that it might be in Mozilla's best interest to make it compatible with all the major browsers if they want this to see any sort of real adoption.
Because until IE reaches Opera levels of usage, there are a large number of sites that don't target programmers that won't be able to build on stuff like this, because they don't want to cut out a big chunk of their potential market.
Black is a culture in the US as well as ethnicity. Barack Obama identifies himself primarily as an African American/Black as does most of the nation. Don't see what's wrong.
That's what society sees him as. And what society thinks goes to a certain degree, because if society was advanced enough to see him otherwise, we wouldn't talk about ethnicity in general.
One of my favourite quotes, from a friend of mine (though I'm sure many others have said it), "We're all beige"
Given that so much software requires installing the JVM, or CLR/Mono run-time, or widget toolkit, or even is specific to an operating system, is it really that much to ask that users install a certain browser which literally runs on any OS, is free and open-source, and can be installed in seconds/minutes?
Why do we rail against people for using the wrong OS, make people dual-boot and run virtual machines, yet installing a different browser is completely unacceptable?
No one minds that so many apps are iOS/OSX/Android/Windows exclusive, but when web-apps don't run on IE it's a problem...
> is it really that much to ask that users install a certain browser which literally runs on any OS, is free and open-source, and can be installed in seconds/minutes?
Yes, it can be.
Can you think of certain situations where doing this is extremely costly (in money, time or both) or do I need to give you a few examples?
In my experience, people displaying this kind of naïveté have never been in a situation of large leadership (where you are in charge of a large organization or when your decisions can impact hundreds of employees across a company).
Of course it could be costly (in time mostly). But eventually, everything reaches end-of-life. Windows XP, IE6, IE10 will too...
For years, organizations said switching to Linux is more costly than paying the MS tax. Recently, many large organizations rolled out Linux installs on a massive scale (European government institutions).
Anyhow, installing Firefox on some workstations is relatively small compared to say, replacing COBOL, or Windows XP...
Edit - and while I don't manage a large computer install base, I use them at a large organization with thousands of installs (a University), and they somehow managed to install Firefox on every single computer.... (but they still advertise COBOL jobs)
> Can you think of certain situations where doing this is extremely costly (in money, time or both) or do I need to give you a few examples?
Yes, I can.
But I can also think, actually, remember, the cost of supporting Microsoft's non-standard Web implementations. For some reason, many people on this thread assume it's legitimate to ask Mozilla to spend time supporting Microsoft products, but it is not legitimate to ask users who want this functionality to support Mozilla's product (by installing it).
Ladies and gentlemen: Actions and decisions have consequences. Choose Windows Phone, and lose a native YouTube app. Choose Internet Explorer and have no access to latest-and-greatest web stuff.
It's as simple as that. There is no reason for anyone to feel entitled to more work spent to support their favorite browser -- even if it was the most popular, which it hasn't been for quite a while now.
> Given that so much software requires installing the JVM, or CLR/Mono run-time, or widget toolkit, or even is specific to an operating system, is it really that much to ask that users install a certain browser which literally runs on any OS, is free and open-source, and can be installed in seconds/minutes?
13 years ago this was not the case. That was my point. At that point, few alternative browsers existed, and Netscape had just released a bloated undesirable release.
Nowadays, the PC itself is a fortress under siege, and Windows only runs on 30-ish percent of all PC/tablets. Webkit is ascendant, and IE persists in being difficult for developers. Now is the time to code for Webkit or HTML5 compliance.
Unfortunately we have a lot of school administrators using our app with their Dept of Ed issued computers. The same DOE that actively encourages everyone to use IE and disallows software upgrades without IT help. Trust me, we try to get them to switch to Chrome/FF but it's an uphill battle.
It's comments such as this that bubble up to the top of the comment chain that often makes me wonder if only a minority of HN users have deployed to enterprise environments with rigid infrastructure policies.
In my more cynical moods I wonder what percentage of users have non-novelty code in production at all.
Fair enough. If you need to support outdated browsers because of someone else's technology choices, that's a differentiating feature for you and your business, and I respect that (and I hope you're charging a decent amount as compensation for the fact you're supporting their older technology).
But if you're interested in the advance of technology, especially when it's pushing the boundaries, a little bit (or a lot) of idealism is a good thing.
Plenty of people make a (from what I hear) very lucrative living programming in COBOL, and I respect them for it. Lots of people still program in Fortran, which is awesome. But that doesn't mean we should be limited to COBOL and Fortran because someone else is...
> "makes me wonder if only a minority of HN users have deployed to enterprise environments with rigid infrastructure policies"
I haven't, so I'd appreciate some perspective on this.
If an org does not allow other browsers besides IE, what are the chances of, for example, having a QT exe that simply wraps a webkit webview installed? I assume all orgs would have some procedure for requesting and then deploying third party software. Is this route an easier sell than simply saying "Please use Chrome or Firefox"?
There is usually a process to introduce new software into the environment. This process can, depending on the rigidity of the environment, take from a few month to years and involves all kinds of hand-offs by various departments. A top of the head list of things that are considered:
- Security
- Retraining
- Support
- Deployment (can we roll this out centrally?)
- (various things I've forgotten at the moment)
This assumes you have the political clout to initiate such a change. Quite often it is part of the requirements which are defined before there is a project ("We have foo, your software has to run on it") and you cannot influence that.
And if one or more of the mentioned parties is actively hostile to you (sometimes only one person who doesn't like you for whatever reason is enough) this can take much, much longer. Or doesn't happen at all.
> Who cares. It's IE which needs to catch up to the standards Mozilla and Google are implementing.
That's interesting. A time ago, people were moaning at IE for coming up with their own standards / CSS things / Javscript features; now you're saying that they should do the same with things Firefox and Chrome introduced?
I'm being petulant on purpose, don't mind me ;). The HTML5 standards are of yet not standardized yet, so tbh I don't know if they actually should.
Yes its IE who needs to implement new techs/standards.
"Tell your users to use a real browser" - Even I don't love IE and don't remember the last time when I used IE but calling it not a "real" browser would be too much I guess :) I think with IE 10 and IE 11 they are making progress. I am sure they will launch WebRTC support as well.
Mozilla has a considerable stake on WebRTC's success, and a good way for them to push it's adoption is to help make useful web apps which rely on it. It would be counter productive, and a huge amount of wasted work, for them to support non-webrtc enabled browsers. As someone who is also actively working with the technology and betting on it's success, I'm actually happy they don't support IE/Safari.
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.
Well, maybe you should contact Microsoft and ask them to provide a port or provide similar functionality. Your users have, after all, paid Microsoft for the privilege of using IE.
That isn't entirely true. The audio chat won't work in IE10, and IE10 support isn't a priority, but most everything else will probably work: https://togetherjs.com/docs/#browser-support
Edit: Ok, looking at the issues tracker, it looks like the current IE bugs basically break togetherjs on IE10. As such, hopefully this issue gets some attention: https://github.com/mozilla/togetherjs/issues/812
There's an age factor. If you submit a duplicate of something from, say, 2 days ago, your submission just turns into a vote for the other submission. But past some threshold (I don't know what it is, and I don't know that anyone other than pg does either), the system allows duplicates. I assume that's by design, as some stories are worth repeat discussions. Indeed, there are a handful of links that have been posted to, and discussed on, HN a half dozen times or more.
You can, AFAIK, also "cheat" the dupe detector by adding query string params, and trickery of that nature. I'm guessing substituting the http URL for the https URL (or vice versa) would also work, if they both exist, etc.
I am building an actual service using technology like this (but we wrote our own, not TogetherJS). It's cool, but don't forget that this is really a "utility" and it's the mix of factors and features that you build on top of this that make an actual product out of it. I'm currently compiling a (somewhat biased) feature-by-feature comparison on creative realtime collaboration tools. Feel free to comment and suggest more products to compare! https://docs.google.com/a/mnt.mn/spreadsheet/ccc?key=0AunvDU...
That's totally intentional, we didn't want to implement a spreadsheet. Yet. ;) I made a list of use cases under the main table that clearly states Google Docs as currently the best tool for tasks like spreadsheets, Word-like document authoring and such. I'm well aware of NIH.
I'm hoping we turn that Firebase fork into a pluggable interface for TogetherJS to exchange messages via other systems. Once that is in place I'm guessing Meteor would be simple too. Most of the Firebase support is in this one commit, and it's notably pretty small: https://github.com/firebase/togetherjs/commit/fdb11887c63342...
What worries me, and I realized this only after trying TogetherJS, is that Websockets don't require a special permission in browsers! So any website with JS enabled is now going to be able to do peer-to-peer? Could this be a can of worms, security-wise?
Sorry about the delay, I didn't see your reply until now. I assume you went see mine.
If you do a search for "websockets cross origin" every result says they are allowed. I currently have something running that is doing cross domain websockets and it works perfectly fine on FF and Chrome without any special effort.
I'm very excited to see so much enthusiasm for TogetherJS.
We are currently building something similar and plan to release that next week. It has lots of similarities but we target a somewhat different market. Some of the differences, you do not need to write a single line of code and it will even work with advanced application that require sign in without sharing security tokens.
We plan to release Surfly next week, but people who are interested in trying it out can msg me and can get a beta account.
86 comments
[ 3.0 ms ] story [ 155 ms ] threadHow could anyone be bothered by something before they know about it?
"We do try to throw up appropriate error messages when a browser lacks the necessary support. (WebRTC isn’t required to use TogetherJS, only to use audio chat, so the error message there comes up if you try to activate that function without WebRTC.)"
So, the issue is not specifically WebRTC support here.
Edit: Also, the official browser support page: https://togetherjs.com/docs/#browser-support So, it could mostly work in IE10, but won't be a development focus.
Tell your users to use a real browser, or write a letter to Microsoft telling them to get with the times...
Even the University I attend doesn't support IE with their web-apps. They support Firefox...
Everyone is happy, except those who want goodies for free. ;)
Firefox + Chrome make up the majority. In mindshare, a vast majority.
Mozilla's only interest is in advancing the web, and web technologies. Not catering to a competitor's old technology...
Suddenly I have the impression I'm on Slashdot in the early 2000's.
If you told me 13 years ago that the US would elect a black president twice, I'd have laughed at you.
Black is a culture in the US as well as ethnicity. Barack Obama identifies himself primarily as an African American/Black as does most of the nation. Don't see what's wrong.
[1] http://en.wikipedia.org/wiki/Black_people [2] http://en.wikipedia.org/wiki/One-drop_rule
One of my favourite quotes, from a friend of mine (though I'm sure many others have said it), "We're all beige"
In the end, everyone is mixed, everyone is human.
Given that so much software requires installing the JVM, or CLR/Mono run-time, or widget toolkit, or even is specific to an operating system, is it really that much to ask that users install a certain browser which literally runs on any OS, is free and open-source, and can be installed in seconds/minutes?
Why do we rail against people for using the wrong OS, make people dual-boot and run virtual machines, yet installing a different browser is completely unacceptable?
No one minds that so many apps are iOS/OSX/Android/Windows exclusive, but when web-apps don't run on IE it's a problem...
Yes, it can be.
Can you think of certain situations where doing this is extremely costly (in money, time or both) or do I need to give you a few examples?
In my experience, people displaying this kind of naïveté have never been in a situation of large leadership (where you are in charge of a large organization or when your decisions can impact hundreds of employees across a company).
For years, organizations said switching to Linux is more costly than paying the MS tax. Recently, many large organizations rolled out Linux installs on a massive scale (European government institutions).
Anyhow, installing Firefox on some workstations is relatively small compared to say, replacing COBOL, or Windows XP...
Edit - and while I don't manage a large computer install base, I use them at a large organization with thousands of installs (a University), and they somehow managed to install Firefox on every single computer.... (but they still advertise COBOL jobs)
Yes, I can.
But I can also think, actually, remember, the cost of supporting Microsoft's non-standard Web implementations. For some reason, many people on this thread assume it's legitimate to ask Mozilla to spend time supporting Microsoft products, but it is not legitimate to ask users who want this functionality to support Mozilla's product (by installing it).
Ladies and gentlemen: Actions and decisions have consequences. Choose Windows Phone, and lose a native YouTube app. Choose Internet Explorer and have no access to latest-and-greatest web stuff.
It's as simple as that. There is no reason for anyone to feel entitled to more work spent to support their favorite browser -- even if it was the most popular, which it hasn't been for quite a while now.
13 years ago this was not the case. That was my point. At that point, few alternative browsers existed, and Netscape had just released a bloated undesirable release.
Nowadays, the PC itself is a fortress under siege, and Windows only runs on 30-ish percent of all PC/tablets. Webkit is ascendant, and IE persists in being difficult for developers. Now is the time to code for Webkit or HTML5 compliance.
In my more cynical moods I wonder what percentage of users have non-novelty code in production at all.
But if you're interested in the advance of technology, especially when it's pushing the boundaries, a little bit (or a lot) of idealism is a good thing.
Plenty of people make a (from what I hear) very lucrative living programming in COBOL, and I respect them for it. Lots of people still program in Fortran, which is awesome. But that doesn't mean we should be limited to COBOL and Fortran because someone else is...
I haven't, so I'd appreciate some perspective on this.
If an org does not allow other browsers besides IE, what are the chances of, for example, having a QT exe that simply wraps a webkit webview installed? I assume all orgs would have some procedure for requesting and then deploying third party software. Is this route an easier sell than simply saying "Please use Chrome or Firefox"?
Thanks
And if one or more of the mentioned parties is actively hostile to you (sometimes only one person who doesn't like you for whatever reason is enough) this can take much, much longer. Or doesn't happen at all.
https://github.com/mozilla/togetherjs/blob/develop/togetherj...
https://twitter.com/jdalton/status/390538182116143105
That's interesting. A time ago, people were moaning at IE for coming up with their own standards / CSS things / Javscript features; now you're saying that they should do the same with things Firefox and Chrome introduced?
I'm being petulant on purpose, don't mind me ;). The HTML5 standards are of yet not standardized yet, so tbh I don't know if they actually should.
"Tell your users to use a real browser" - Even I don't love IE and don't remember the last time when I used IE but calling it not a "real" browser would be too much I guess :) I think with IE 10 and IE 11 they are making progress. I am sure they will launch WebRTC support as well.
"So @togetherjs blocks IE via $.browser.msie. Glad IE11 changed their UA string so it bypasses that nastiness. Works great btw :)"
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
Edit: Ok, looking at the issues tracker, it looks like the current IE bugs basically break togetherjs on IE10. As such, hopefully this issue gets some attention: https://github.com/mozilla/togetherjs/issues/812
https://www.hnsearch.com/search#request/all&q=togetherjs&sor...
You can, AFAIK, also "cheat" the dupe detector by adding query string params, and trickery of that nature. I'm guessing substituting the http URL for the https URL (or vice versa) would also work, if they both exist, etc.
Literally just deployed, absolutely love it:
http://hackurls.com/#&togetherjs=global
One liner copy-paste for community on your website. I can finally talk in real time with my users and understand why the use my website.
I'm not there could be an possible integration with Meteor too.
[0] - https://github.com/firebase/togetherjs
2. WebRTC allows P2P. Can't see how it's a security issue.
If you do a search for "websockets cross origin" every result says they are allowed. I currently have something running that is doing cross domain websockets and it works perfectly fine on FF and Chrome without any special effort.
We are currently building something similar and plan to release that next week. It has lots of similarities but we target a somewhat different market. Some of the differences, you do not need to write a single line of code and it will even work with advanced application that require sign in without sharing security tokens.
We plan to release Surfly next week, but people who are interested in trying it out can msg me and can get a beta account.