Atmosphere based packages are specific to Meteor, whereas npm based packages can be used across the entire Node landscape. This means npm based packages are more popular, more diverse, and often times better supported (due to npm’s larger user base). This is why Meteor decided to officially start supporting npm packages way back when. The general rule of thumb now is that if you can find a package that does exactly what you want, and it’s available via npm, use it.
The above being said, it’s important to note that Meteor’s package system is actually quite a bit more powerful than npm. The biggest advantage is that Meteor packages can be built for multiple architectures (e.g. client / server), from the same codebase. So if you want to provide both client and server based functionality, in a nice cohesive package, then Atmosphere based packages usually make more sense. There are many other advantages that Meteor’s package system brings to the table (advantages that have helped Meteor thrive), which I’ll let @benjamn explain ever so awesomely:
Meteor packages have a lot more going on: they have to be built for multiple architectures (e.g. client and server), they can run code on application startup (rather than waiting for you to import them), and they are compiled when you build your application, instead of getting pre-compiled by the package author at publishing time. These are important design decisions that we are not likely to abandon, since they make Meteor packages much more powerful than npm packages, and allow us to continually improve the way compiler plugins like ecmascript and babel-compiler work, without worrying about code that was compiled long ago, whenever some Meteor package was last published.
I’ve started to prefer NPM to Atmosphere as it has much broader community as well as I can find not only Meteor packages but also any kind of Javascript libraries, Cordova plug-ins etc. which is deployed to a Meteor project without a problem. I love this flexibility of Meteor; not being a strict framework but a rather a library enabling us working with other useful tools smoothly.
Of course, if there is well maintained Meteor package on Atmosphere.js it will be much more useful than its NPM alternatives as it organically integrates with Meteor system (Accounts, DDP, etc.).
To sum up, it depends more on the quality & suitability of library/package itself not only on being at Npm or Atmosphere.
In regards to security, I think directives are really going to help with that. If you put those rules right in the schema, you don’t need to worry about who can query what at the resolver level.
What is meteor other than a build system and an easy-to-use (but not necessary to use) account system (and a jumble of additional packages)?
It’s like saying “Gulp is Dead”. As if you can never move from gulp to webpack some day, if it really called for it.
If you use meteor and mostly NPM packages, you’re basically just using node with mongodb.
It would be nice if all meteor packages were just moved over to be node packages, just because I feel people would be more likely to maintain them, but whatever.
I’ve shared some thoughts here that since 2015 Meteor can be used in different modes (as a full stack, backend, or build tool) which I think are not mutually exclusive and each has it’s own use cases, and many threads including this one are, in my opinion, overloading the concept.
I’ve also suggested to embrace the flexibility of the platform, which is why I personally started using it after 2015, and not get stuck on one usage pattern over the other or deploying provocative titles like the one used in this thread.
And lastly for the general public perception, I think more support to VueJS (similar to react/angular in terms of tutorials) and a little of PR work communicating the new Meteor capabilities will reverse some of the FUD that happened in 2015. Alternatively, we can ignore the FUD and try to build great products with what I think is the best Node.js framework
I’ve read this post. This discussion and @nosizejosh info about tweet from Taylor Otwel inspired to me to write this article.
By the way, when we started to cooperate with corporations, and outsource projects for them using Meteor, is was something fresh. Not only for us, but mostly for them.
If the corporation has its own dev team, then they usually use older solutions and technologies. It’s not someone’s fault, but only a fact.
When we come to them with Meteor, it turns out that our develop time is almost half as long as theirs.
Meteor is amazing stack and like many of you said give very good flexibility.
Totaly agree with your comment. Meteor is losing focus going after Apollo and GraphQL (It is good to have others alternatives). Focus on React and left Blaze, it is all the reason that many developers choose Meteor. It is very frustrating to see Meteor left those. They should give all efforts to improve Blaze and Meteor core packages.
But there are many happy react, vue, angular, graphQL users on this form as well who welcomed and embraced the flexibility. A lot of folks clearly appreciate the openness and integrations with the wider ecosystem.
Yep (all three of our products ). We have some micro-services to do document generation and random stuff like that, but all user facing stuff is in Meteor.
Many people had just gotten into Meteor and loved it because of how fast you could create a fairly advanced, interactive, website. Meteor took care of almost everything, you just needed to write code almost wherever and however you wanted. If you needed extra functionality you headed over to Atmosphere and grabbed it. It was easy to learn and it was easy to teach.
Then suddenly everything changed.
In hindsight, it did not change at all, we were just given the options to be more “industrial” with our structures and was also given options to choose frontends. Meteor got better, but it did not feel like that. I think it was down to a bad communication strategy from the MDG, because myself and many with me got the feeling they said “you are doing it wrong, this is the way you are supposed to do it”. Suddenly Blaze was dead and it was all about npm, React, Angular, Apollo and whatnot.
There is a time when you learn and there is a time when you produce. In the middle of your production you do not want to hear that the stuff you use are on a death list. In the middle of production you do not want to change the development strategy in a direction which contains mostly question marks.
I think MDG made the right choices, Meteor as it was could not go much further, but they should have been more gentle, they should have marketed the “new way” as an alternative for those who wanted to do a more proper architecture without signalling the death of the old way. Especially since that is what it was. The old way did not die. Maybe it never will.
The new way is better, but different. It is a bit harder to learn but it’s worth it. For some. For others, the “old way” is unbeatable. “You need a site for your cake recipes? With voting and comments? Facebook login? PDF printouts? No problem, you have it in the afternoon”
I’ve found meteor a couple months ago. I studied it, learned it, practiced it a bit. I loved the meteor approach, specially Reactivity and Optimistic UI out of the box.
I’m about to create a proposal for an App with potential 10 years life. I do not see new posts from MDG, or new great enhancements, and roadmap, at least I can not find it. Do you guys can lead me somewhere to support my proposal?. Since I have not written a single app yet, I still wonder if Meteor is the right technology for the next 10 years.
I don’t think anyone can speak with any level of confidence on the state of a particular piece of software 10 years in the future. That being said I think that Meteor development is still going strong with MDG and the Community doing lots of awesome work. I personally don’t see Meteor falling by the wayside anytime soon.
When things started really changing around Dec. '15, I was cautious. Then over the course of a year or more, as MDG move away from Meteor and focused on Apollo, I became worried this framework I invested so much in would enter a slow decline.
But in the last year or so, I’m pleased to see that Meteor’s development as progressed nicely with @benjamn@abernix & @hwillson at the helm. And the clip of progress has seemed to actually increase, with MDG opening up to PRs from the ‘outside’. Impressive.
Been building apps with Meteor since '13. Never been let down by the framework. Old apps still keep working, new stuff is easier to build than ever.
I think that, like with most good Open Source Software, the question is not whether it’ll still be there in 10 years, but whether it’ll help you grow with it or it is going to leave you behind.
