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.
2 Likes
That for me is very unique and powerful feature.
3 Likes
I love this!
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.
2 Likes
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.
3 Likes
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 
8 Likes
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.
6 Likes
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. 
1 Like
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.
1 Like
Qualia is still loving Meteor
14 Likes
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.
It’s a bit outdated at this point, but I gave a talk at Meteor about Qualia https://www.youtube.com/watch?v=Iguedyg2cOI
I can legitimately say that Meteor has been an important factor in our success so far.
18 Likes
As I see it, this happened:
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”
6 Likes
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)?
Add on top of that Reactivity and Optimistic UI powered by minimongo.
3 Likes
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.
Any comments on this?
1 Like
Will you share some of your data, what you measured? I was thinking of using Gasby for static websites, but I’m curious how Meteor performs.
1 Like
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.
5 Likes
@copleykj, I agree.
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.
8 Likes
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.
You will be growing with Meteor.
6 Likes
It’d be great to get a wrtie up on this.
In the meantime, React Static is pretty sweet too - and in some ways better than CRA.
(this is not to speak against Gatsby)
1 Like