Maybe I'm just not the audience for Meteor, because while it looks like a great project but as a nodejs guy, the fact that it hides itself away from the platform and turned away from the fantastic npm makes me sort of weary about it as a whole.
But I imagine people coming from rails or whatever don't find this a problem at all.
Personally, I agree that sticking with npm is the best solution. We have managed to do this with Derby (http://derbyjs.com/) while still providing easy app creation, automatic packaging, realtime data syncing, and reactive model-view bindings.
It's awesome to see that Meteor is now permissively licensed, but I would prefer to see them embrace npm as well.
After all, that's the point of an API - to hide the dirty details.
I mean, I've not touched assembly code in over 10 years. I've not touched C++ in 10. This is a good thing, but I do remember saying the same thing about Java about hiding memory details. Now none of these languages require heavy memory management and hide nearly all those dirty details.
It doesn't seem like meteor is ready for prime time, but it is impressive (like RoR or roo) how you can make a site in less than 10 minutes.
SocketStream is a nice framework (also in early stages) that embraces npm and other node conventions. It doesn't support reactive programming out of the box, but I wouldn't be surprised if someone decides to build a module for it.
Hi simplify. I'll be releasing an new version of SocketStream this Sunday which allows developers to do just that.
The new Request Responder API will allow developers to experiment with many different approaches to models, model synching (e.g. with Backbone.js and Ember.js) and reactive templating.
Rather than put opinionated choices about models and clients-side frameworks into the core, we'll ensure the best third-party modules are fully documented and supported before featuring them on our website.
But I imagine people coming from rails or whatever don't find this a problem at all.