Let’s use Bootstrap as an example. Would one be better off using the twbs:bootstrap Meteor package, or the npm bootstrap package? Are there any advantages to the latter, other than maybe more rapid updates? Obviously in some cases it makes more sense to use NPM, like with React or Stripe, where you have to wait for someone to update the Meteor package which is essentially a wrapper.
Thoughts?
Pretty sure Meteor is heading in the direction of deprecating Atmosphere in the style they have with Blaze, so that’s a bonus point for NPM.
If you can use NPM use it as possible as you can. I’m starting to move some of packages to NPM. Specially, FlowRouter and related tools.
You know… to be totally honest, I wouldn’t miss Meteor’s package version system. I’ve posted a couple times how utterly confusing it is, and shown how the documentation on how it works does not line up with reality. NPM’s is so much more straightforward. 
I’ll start using NPM more for things, I think. Bootstrap will be a no-brainer especially when 4.0 is released and its default CSS preprocessor is Sass.
Yesterday, @gschmidt told on some other thread, Atmosphere packages will be moved to NPM eventually.
May be not in this year. But, if possible we should try to use NPM modules.
(But that’s hard always to do)
That would definitely take a really long time. There are so many packages, and so many Meteor apps out there that rely on them.
I was trying to import https://www.npmjs.com/package/bootstrap-less in my apps less, but without success, do you have any idea on how can I achieve this?
Some of the more tightly integrated packages dealing with meteor’s specific database situations like the autoform/schema stuff I think might stay with atmosphere.
I’m currently running into this issues when combined with using React, Webpack and Material-UI. Things like ending up with two versions of React (the NPM version and the Meteor version)being loaded because of dependencies on packages providing react or material-ui integration,.
I haven’t had any collision issues. Why would you need Webpack if you’re using Meteor 1.3?
Code splitting (root url went from almost 30mb to 3mb), and it’s way faster in regard to the hot reload. I’m still pretty new to webpack, react and the new modules so I might be missing something.
I’d say go with NPM as much as possible unless a Meteor package provides some specific advantage. For example, mrgalaxy:stripe combined the essential Stripe packages into one, and that was super easy to install with a single command.
Another example: I’d much rather install SemanticUI from Atmosphere than having to set it up from NPM.
So, it really just depends on which one benefits you more…
Of course, now that NPM is supported, package authors will be able to choose between NPM and Atmosphere for publishing. Again, in that case, I’d say pick whichever ultimately makes it easier for the end user.
Lodash is really easy to import from NPM for example, so there’s absolutely no need for an Atmosphere package in this case.
I thought that package was deprecated in favor of copleykj:stripe-sync?
@ffxsam Could be. I guess I haven’t updated, if that’s the case, but I don’t need to because everything is working and is doing what I need it to do.
Interesting. I recall trying to use it and running into issues, but I don’t remember what. Maybe it was updated though.