[fourstar]

To be honest, Meteor is nice and a very ambitious project but the fact that you are writing an application with it means you are probably wedded to it.

That's why I've been using Express for my middleware, npm modules as needed, and mongoose as my db wrapper (or if I want to switch it out for redis, I can do so easily). Not sure how easily I can port my "meteor app" to a different framework that comes along.

[JPKab]

I've been playing with Meteor lately, and I can certainly see some element of lock in when using it. That scares me naturally. However, the positives are: 1) Speed: It is insane how little work has to be done to stand something up that is decent and funtional 2) Packages: Not a long list, but the ones that exist are ridiculously easy to implement.

Seriously, the sheer amount of work that you end up NOT doing almost makes it feel like cheating. I can completely understand why people don't like it. I fully intend to build something in Derby soon, and to examine Rendr. But I'm wanting to build an enterprise focused metadata management app, and Meteor seems to me to be the right way to go, because at the end of the day I just want to get something built that provides a capability.

[btown]

Agreed. You can still get a lot of the code-reuse benefits without lock-in by using tools like Browserify and Socket.io. With Browserify (or any of the other CommonJS packagers), I can use the same lib directory for both my client and server code, and all my utilities/templates/validators/algorithms/NPM modules work on both. One of the most awesome things about Socket.io that's not really emphasized in the docs is that the API for client and server is almost exactly the same, so you can change your mind almost on a whim whether you want a certain RPC to work on the client or the server.

To me, it's a lot easier to "grok" exactly what's going on when you're using a simple middleware layer and a simple socket framework, than when you're using a full-stack solution like Meteor.