Looks awesome! Is there a reason you chose Meteor over other options? Was there some key functionality or development requirement that made Meteor the obvious (or only) choice?
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.
[+] [-] halisaurus|12 years ago|reply
[+] [-] philcockfield|12 years ago|reply
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.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] timhaines|12 years ago|reply
Pocket's Support person: https://twitter.com/saysjustin/status/456165953718341632
Stripe's Twitter support person: https://twitter.com/kitchenettekat/status/456150203066617857
And you can look at the via tag on the reply tweets sent from @tweetbot and @npmjs_support to see that they're using it.
[+] [-] kfd1|12 years ago|reply
[+] [-] timhaines|12 years ago|reply