Cons: 0. It's non-npm package manager feels like NIH to me I was initially put off by this as well, and it compelled me to check out Derby.js as an alternative

Cons: 0. It's non-npm package manager feels like NIH to me I was initially put off by this as well, and it compelled me to check out Derby.js as an alternative since it looked like Derby wasn't ignoring widely adopted tools like grunt and NPM. But after using Derby for a bit, I noticed that I was back to doing more boilerplate coding than I'd like and I decided to give Meteor another chance. Now I see the the benefits of the closed ecosystem. In Meteor you are dramatically constricted in choice, but everything that is available to you works effortlessly together. If you install a package, you pretty much know it's going to work. It's almost like if you imagined Meteor as a Ruby framework (god forbid), and we ignored all of the client-side magic, this philosophy alone would provide value. Because this framework might include pared down versions of capistrano, Mongoid, Devise, Unicorn, Heroku and others and integrates these tools together into one well-thought-out holistic whole. And all of the pieces of this project moved forward in unison, instead of forcing developers to play whack-a-mole with all of the moving parts. So beyond the beauty of no-fuss reactivity, the benefits of tight front/backend coupling, being able to code in Coffeescript from top to bottom (which is a big selling point to me), I really think that what is currently seen as a negative regarding the ecosystem is going to develop into one of its over-riding strengths. Suffice it to say, I'm sold on Meteor. :) Both in its current state given its youth, and in the direction it is moving.