Hacker News Reader

Comment by stuffihavemade | Hacker News Reader

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.

View on HN

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.

I don't think this will change. I think one of the design goals is to have it's own ecosystem.

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.

http://www.youtube.com/watch?v=HAcN3JyQoyY

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?

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.

How is having all second party modules be global automatically a convenience? That sounds like the worst possible way second party modules could work.

Throwing away a package manager as great and as tried and tested as NPM, which could easily be used seems so counter-intuitive.

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

Reply on news.ycombinator.com