Here was the design criteria we were holding in mind when deciding on the technical stack to employ for Respondly. To support the "team collaboration" story we knew it was going to be a heavily JS based "native like" UI experience. So basically a rich single-page app that used push-state and web-sockets a lot.

Meteor is nice in that it folds a number of technologies into the stack that when combined are extremely powerful, not least of which being Mongo on the server AND the client, which helps a lot in reducing the amount of code you typically have to write for dealing with invalidating shared data when it changes between users. It achieves this by having the Mongo API replicated on the client in JS, which is really a thin proxy to the DB on the server. So your coding against Mongo as though it were actually in the browser, and Meteor handles the data syncing in the background. It sounds a little magical, but it shakes out to be a really helpful abstraction to sit behind.

The real kicker for us, though, is that we can lean on the hard-core architectural work MeteorDG has done to ensure a real-time, web-sockets based system of this kind can scale readily when there are ton of connected clients.

By avoiding rolling that sort of architectural plumbing ourselves we've been able to focus more on the feature set.