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...
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.
One way a country could get to this would also be revenue-neutral taxes. A revenue-neutral carbon tax, for instance – a lot of taxes would be collected, on the theory of limiting output, or maybe you could use the theory that you were charging for access to the environmental load, which is a public resource held equally by all people. To make it revenue neutral then you have to return that tax money to people. You could cut taxes or put it some bullshit "lock box" but that's nonsense thinking. IMHO the only reasonable way to keep it truly revenue neutral is to directly funnel the money back to individuals. A basic income would be the result.
People freak out that a carbon tax would be regressive, and it would, but the return would be so progressive that it would more than undo that.
In general I think this kind of theory should be applied to more use taxes – places where ostensibly a tax supports something like roads, making a system self-supporting. But the use taxes only address a small part of the cost of roads, they don't consider the opportunity cost of using land for roads and they don't address the negative externalities. A use tax that included all of that, and returned some portion to people, would be a fairer tax. In that context something like congestion pricing would be fair in a way that it isn't currently.
ISTM this would be difficult to study for periods that predate the phonograph? I guess one could look at rhyming poetry, but it's not clear how much that would help.
I am disappointed when I hear the term "socio-economic factors" in discussions of education. First, as if "economic" wasn't enough you add in "socio" to create a term that means "factors coming from every part of a person's life". Of course there are socio-economic factors.
But I dislike it particularly because often it feels like a statement: we don't know what the causes are (which is why we make the weakest possible claim by using this incredibly expansive category), and we aren't going to try to find out.
So I particularly appreciate this program, and the research it is based upon. We have a pretty well identified phenomena: talking a lot to kids, at a young age, helps them. A lot. And some people talk to their kids a lot more than other people. We should delight in this finding! We have a pretty clear way to identify a lot of kids whose lives could be greatly improved through changes in their parents' behavior, and that change is widely accessible.
It's this kind of finding that penetrates "socio-economic factors" and in the process identifies something actionable.
Some of the best hackers &| hustlers I know come from average to slightly-below average backgrounds. The biggest challenge for anyone, given any background, is what they tell themselves they can't do.
In addition to talking, it's important that the parent is a decent human-being. An awful person interacting with a kid probably does more harm than good. I don't think there's much correlation with decency and socioeconomics.
--
"Give me guys that are poor, smart, and hungry and no feelings." - Gordon Gekko
When you say that some of the best hacker and hustlers that you know come from unimpressive backgrounds, does "some" mean "most" or "a few" or "hardly any"?
Which means older people, who have generally been much less able to participate in startups at an early stage, can now have affordable insurance as individuals. Before not only could someone older (though not necessarily very old) be burdened by a high cost of insurance, but you could never be sure that your insurance wouldn't spike to some unrealistic amount. After a certain age insurance companies have been very willing to price a person out of the individual insurance pool (and force the person to move to government or employer insurance). Also god forbid you have a kid.
[Team member here] We haven't been very focused on the hosting story, in part because lots of people have their own requirements, and we can't predict what they are. And maybe because predicting what they are is boring. I know some hooks for New Relic have been added to the server. It's also a super-simple server that only keeps things in memory, so it's pretty darn easy to handle. Just one file: https://github.com/mozilla/togetherjs/blob/develop/hub/serve... (and only one dependency, for WebSockets).
Both people are accessing the website as themselves. If one person doesn't have permission to see a page, for instance, then they won't see it. And yeah, whoever hits save is the saver ;) Doing something richer than that requires application-specific integration, which we want to support, but we also want to take cues from developers about what that should actually look like. This is one idea we have along these lines: https://github.com/mozilla/togetherjs/issues/372
On principle we keep the server simple, echoing messages back and forth between clients. In practice it's quite hard for two browsers to connect directly to each other, and while we want to support that kind of architecture in order to get it working we still need to simulate P2P using a server.
WebRTC makes it possible, but not easy, nor abstracted. You still have very long connection strings to establish the connection, and those strings change as you move around, so it's not something we'd want to ask users to send to each other in order to establish a connection. The approach usually used is a server where the two people rendezvous to exchange the connection strings. That server is kind of like what we have – but then once it's in place, changing over to WebRTC just doesn't seem as exciting. (And even then the connections are slower to establish and less reliable than WebSockets.)
[Author here] The big way TogetherJS differs from many of the other realtime products out there, like Firebase or (to a lesser degree) ShareJS, is that it doesn't do any storage. It coordinates real-time sessions, but it's not there to take the place of the application, instead it augments the application. If your application has persistence, it has traditional persistence. Whatever auth system you have is your own. At the same time while it dodges any persistence, it extends the scope beyond what those other tools typically do to include more with session management and the standard tools that I think are needed for collaboration. There's nothing exciting about text chat, but you need it anyway.
Still, ignoring persistence I think will help keep the surface area of the TogetherJS smaller compared to some other tools. Or at least focused on other things.
People have mentioned the idea of being able to chop TogetherJS up before, but I have a hard time seeing how that would actually work. For instance, the architecture is built around a pretty dumb server, so hooking into Streams would seem counter to that principle. And just allowing for the possibility would add a lot of complexity. Ultimately the UI is actually the bulk of what makes up the TogetherJS code (or maybe it's the part I find hard and so I feel like I spend a lot of time with it), and I don't know how to make this kind of UI while being modular. Without the UI I don't think it's nearly as compelling a project (becomes more like ShareJS, or Firebase, or Google Drive Realtime API – neat but a big investment, and sometimes only appropriate for greenfield projects.
Anyway, I'm certainly interested in how people want to extend or integrate with TogetherJS. I'm skeptical of splitting it up into pieces, as it is theoretically easier to do things that way, but I expect in practice it will just leave a confusing pile of pieces that aren't fun to put back together. But that doesn't mean that there aren't use cases worth exploring... and with some creativity there might be other approaches to handling those cases.
[mozilla employee here] There's no catch except an absence of a commitment to keep running it. Mozilla Labs is charged with figuring out how to make the web better. We think this could help make more apps collaborative. You tell us if we're right.
