How can there be best practices when there's no production ready software? Best practices aren't derived from first principles -- they're a reification of all of the human experience that has gone into writing and MAINTAINING software systems.
The thing that concerns me about Meteor right now is that they seem to be fighting the use of the existing node ecosystem (e.g. not using npm, fibers) which makes it harder to use existing node libraries. Derby.js (http://derbyjs.com/) in contrast, build upon existing node components and plays nicely with npm.
I agree, but Meteor is still young and it actually has a reason for doing it that way. Meteor doesn't have a built-in module system right now, so when you add something like underscore.js to your Meteor project, you don't need to require("underscore"), it's simply available on both the client and server globally.
I feel like they chose to go for convenience rather than consistency with existing practices.
But like I said, Meteor is still in its infancy. It's entirely possible this will all change down the line.
well its called "smart" package manager so perhaps the team believes NPM is a "dumb" package manager? But isn't a package manager suppose to be dumb? Sounds like over-engineering already :P
To me, that's not a compelling reason to avoid using npm. I haven't played around with node that much yet, but Rails uses ruby gems just fine, and it doesn't require require everywhere. Even if you do have to use require in some manifest file, that seems to be a small price to pay to interact with existing code.
I think their design goals is to make it easy and simple to build web applications. If they are building their own ecosystem its because they feel it is necessary to do so in order to achieve that goal.
This talk gives a good intro to Meteor and after watching it, really doesn't seem like they the kind of guys to not embrace NPM if it could work as well for them as building out their own.
I am interested in this. Could you reference something specific to this video that speaks to the kind of guys they are and how these character traits relate to the decision to not embrace npm? (I just don't want to go digging in the video) Or are you just talking about general intelligence?
I appreciate the brief diversion at the end (which I would summarize as 'make sure your users can't delete your entire database'), but it seems like there's nothing on which to base fundamentals/best practices for Meteor security yet...
Meteor is interesting but like others, I have some concerns. It's position within node.js community is a little strange to me. Also, this idea of "best practices" for something so new is just a little odd. Is it really a "baked" state where people can really build non-trivial apps or complex apps? I think you need a baked state plus time for best practices to actually develop.
"Note: Execute $ meteor remove autopublish on every project from the root project directory. It publishes all your data by default to the client and is poor practice."
This note does not belong in any article that also contains the heading "What is Meteor?". You should remove autopublish eventually, but it's a great piece of scaffolding.
