|
|
|
|
|
by tferris
4882 days ago
|
|
Thanks for your thoughts but how can a walled garden like Meteor can be the best choice for anything? Meteor tries to create an entire new ecosystem using Node's merits. The reference you posted lists pseudo reasons for choosing a new package system. I don't know if here is the right place to discuss them but some of them are heavily misleading and primarily business-driven and motivated by a developer's lock in. It's important to state that especially Node's npm is one of the most modern package managers around and already solving issues like repeatability, asset building and bundling (npm's concept is totally different though). Sure there's a need for package management on the client side but coupling everything together is not the answer. I highly appreciate the talented team behind Meteor and their achievements up to now but it's sad and a deal breaker that they choose this non-npm route. As a final point, I am aware that maybe it can be good to have competing JS on the server ecosystems and all JS users will benefit at the end from this competition. |
|
As Geoff said, in the upcoming release, it'll be trivial for a meteor package to wrap a npm package and integrate it into the 'walled garden'. If and when a client side package manager appears that everyone is using, I'm sure they'll do the same.
So, I'd expect a situation to arise which is much like that of rails + gems; a ruby library that is not completely tied to rails is usually published as a stand-alone gem, with a X-rails gem which does the railties stuff.
Perhaps it's not as clean as it could be, but I think it's unavoidable when you consider some of meteor's design decisions (synchronous APIs being the biggest one) -- debating these is of course a separate issue.