[tferris]

Isn't that what Node.js is all about? Modularity? To get away from the monolithic, bloated, one-fits-all frameworks like Rails? And maybe there's something between "Rails" and "HTTP" (Sinatra => Express JS => modularity).

Building a new framework on top of Node but cutting out the fabulous npm and its huge ecosystem, instead unnecessarily introducing an own package manager/middleman in order to lock in developers and not following (or rather ignoring) Node's core principles is a brave step. Good luck guys, you'll need it.

[tmeasday]

Definitely! There are things between meteor + websockets (socketstream and derby come to mind), and depending on your project, sometimes they are going to be the best choice. Just like sometimes Rails is the best choice and sometimes Sinatra is.

I was just saying that it's a rare case that going all the way down to the metal, and using websockets alone is going to be that best choice.

On the second point, I'll won't speak for the meteor team (which I'm not a part of), but here's what Geoff Schmidt recently had to say on the matter: https://github.com/meteor/meteor/pull/516#issuecomment-12919....

[tferris]

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.

[tmeasday]

I don't think it's quite as bad as you make out / think.

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.

[JPKab]

I share your concerns regarding "walled garden." Are you aware of Meteorite, and the Atmosphere repository? Essentially Meteorite is an open package manager which wraps the meteor functionality, and allows installation of all of the third party packages on Atmosphere.

I do want to point out one difference I've noticed when using Meteor: ease of implementation.

Once the "accounts-ui" package is added, here is the code that is added (in two respective files) to implement a login/registration function:

    <div style="float: right; margin-right:20px;">
		{{loginButtons align="right"}}
    </div>

and

Accounts.ui.config({ passwordSignupFields: 'USERNAME_AND_OPTIONAL_EMAIL' });