Facing the truth: Meteor became legacy in 2016 :-(

I went through the Meteor docs and it doesn’t look good…

Here are most of the packages referred in the docs, with their last commit date.
As you can see, in 2016 most packages stopped being developed.

These are not just some random packages. These are packages that MDG thought should be included in the docs, because they offered significant value for Meteor devs. I use many of them and it is very worrying.

Because the sad reality is, all these packages are legacy. All those people stopped developing those packages a long time ago for some reason. Probably all the people using those packages moved on as well.

How did this exodus happen really?

Seems I stayed way too long in the Meteor party.
Time to leave…

practicalmeteor:mocha - 14 Jul 2016
kadira:flow-router - 11th jan 2017
zimme:active-route - 18th oct 2016
kadira:blaze-layout - 25th nov 2015
arillo:flow-router-helpers - 13 jun 2016
simple:rest - 6 May 2016
nimble:restivus - 24 jan 2017
aldeed:autoform - 24 may 2017
aldeed:collection2 - 27 Dec 2016
useraccounts:core - 23 Oct 2016
tap:i18n - 22 Oct 2016
percolate:momentum - 22 jun 2015
dburles:collection-helpers - 26 Oct 2016
tmeasday:publish-counts - 14 Dec 2016
percolate:find-from-publication - 21 Oct 2015
percolate:migrations - 28 jul 2017 (not really, check the commits)
mdg:validated-method - 30 Aug 2016
useraccounts:unstyled - 11 Apr 2016
useraccounts:iron-routing - 11 Apr 2016
iron:router - 17 Apr 2017
alanning:roles - 27 Feb 2017

1 Like

I can’t think of anything that happened in 2016 that would have impacted the development of 3rd party Meteor packages …




Most new packages like uniforms (a react based sort of version of aldeed:autoform) are being distributed through NPM.

But some of the items on your list have notes right in the readme about deprecation. For example aldeed:collection2 has been deprecated in favor of aldeed:collection2-core and aldeed:simple-schema (meteor-simple-schema in github) is replaced by npm’s simpl-schema (node-simple-schema in github).

I do agree about much of the Blaze ecosystem haven fallen silent, but as someone using both Meteor and webpack, I can say unequivocally that I MUCH prefer Meteor in most cases, and will continue using it for the foreseeable future. The integration of NPM has really changed everything, and we are still getting really great new tech like dynamic imports. There’s nothing legacy about Meteor.


I don’t think your conclusion is valid. The core is being actively developed and NPM is hosting the active packages.

Some of the stuff you listed are focusing on DDP and meteor collection, these have already been battle tested and MDG focus on graphql is clear in the roadmap and you can use it today with Meteor.

Other packages you listed are pertaining to blaze, but React, Angular and vue are all supported and each have their own routers and active communities.

So again I think your conclusion is invalid.


Also we still get some good meteor packages now, but more for the backend, see http://jagi.github.io/meteor-astronomy/
This one is kind of new right?

Satya: Any echo system with community contributed components will have the issue of original developer moving to something else due to various reasons. However Meteor core is being worked on and improved for better. Its up to people like yourself to pull their sleeves up and use the new cores and contribute back to the community. Meteor fits certain needs and I for one will continue to use it .


Why are you worried? Do those packages suddenly not work anymore?

All of those packages work fine in production. Meteor’s core hasn’t changed in a long time, something that worked 2 years ago will still work fine today. If it’s been published for a long time, has a lot of test coverage, and lots of users using it regularly, it’s not legacy, it’s a mature technology. Nobody needs to be changing these packages, they work as is and always will. That being said, they’re all open source and anyone is free to contribute or fork as they desire.


Why do you so eagerly expecting the regular update? They working isn’t it? You can add some features, but it is not necessary. Personality i do prefer stable versions of the packages, rather than every week changing.


Blaze is arguably legacy, but Meteor + React is no less up to date than WebPack + Express + React.

That said, is Blaze or Meteor or React or any other library really the thing that’s going to make or break you business/project?


In addition to the above comments, it may be added that the addition of perfect code splitting this year made Meteor one of the hottest things going for node.js development.

1 Like

I have to agree with other responders here: Meteor is not legacy although many of these packages may have become legacy. Blaze is still alive, but may slowly die out, but Meteor is going strong albeit in a new and improved form. A while back I had the same feeling and searched for a new framework/ workflow and settled on React for the View layer, then settled on GraphQL as the REST of the future. Then I was surprised that MDG’s Apollo server (IMHO) has more support and docs than Facebooks own GraphQL server. Then I tried packaging these together and realized that Meteor would do that for me! So my Odyssey led me right back to Meteor.

Meteor has changed a lot, there’s a lot more to learn, it’s not as newbie friendly as it was before, but it is better than it was before and is on the cutting-edge of technology.

My summary: Many of the packages in your list may be legacy (many have been replaced by better packages in NPM) but Meteor itself has moved beyond those packages that have become legacy.


Despite huge legacies, the universe is expanding at the speed of light. And living on earth is a very stable thing. Let’s trust Meteor.


Just because a package has no more development does not mean things are over. Some packages, especially if they are very small and specific, are good and need no development after a certain point. You have to look at more than just last commit. See what bugs have been reported if any. And if there are bugs, are they actual bugs or more in line with feature requests?

Can a moderator please close this pointless thread? I meant no offence - the contributions are not pointless, but the subject definitely is.


So, the conclusion here is:

The Meteor Guide is almost completely based on deprecated packages. New devs should not follow these guides and not use the best practices outlined there / use any of those packages in production. But Meteor itself is doing just great.

Instead, do your own research on NPM and find & use packages that solve your problems and are well maintained. So you can reliably build a long term business on Meteor.

Might as well use something like FeathersJS then (been using that lately, it is awesome and as easy plus reactivity for any database…)

I’m really sorry that it seems you’ve had an incredibly frustrating experience with trying to figure out best practices. I hope that experience can be improved.

I think other replies above explain why a package may not receive updates. Many of the packages listed on npm’s most-depended-upon package list haven’t been updated in months or years, yet they are still critical to the npm ecosystem. A lack of updates doesn’t necessarily mean anything, nor does it mean that you shouldn’t use something in production – this appears to be a conclusion you came to yourself. Additionally, authors for many of those packages you listed are still active in this community.

There are great packages from the npm ecosystem which play along with Meteor very well and for quite some time now, we have encouraged Meteor developers to consider releasing new packages on npm where appropriate.

The Meteor Guide is supposed to be an opinionated stance from MDG and the community on what works great with Meteor, but not meant to be the only suggestion by any means. I’m also not claiming it is 100% up to date and we can hopefully improve it.

The guide is open to community contribution. Instead of being unnecessarily critical of its suggestions, I ask you to help improve it! Much like free, open-source software, open-source guides need help too!

If there are npm alternatives which feel better than those offered in the Meteor Guide, please open issues on the GitHub repository to make a case about why that might be. For example, if you think Uniforms is much better option than aldeed:autoform, try writing about it like this community member did. If you can rally community behind your thought process, then improvements can (and should!) be made to the guide to make it easier for the next developer to come along.

I’ll be honest, you seem to have started this thread with your own conclusions and biases. You labeled the thread and many packages “legacy” before getting detailed information about whether the packages were actually legacy (even if that may be true in some of the cases). If you feel FeathersJS is better for you, then by all means, use FeathersJS. Is it necessary to really drive your point home if you aren’t interested in continuing to use and improve Meteor? If there are particular strengths you think FeathersJS has, then perhaps you could create specific productive conversation (not broad, over-reaching declarations like this post) about how Meteor could improve? Or maybe you could help improve the guide and keep a “new dev” from having to go through the frustration you seem to have gone through?

Again, I’m sorry you had to go through this frustration, but ultimately, it would be best if you would start a new thread asking specific questions about specific packages and whether they are still the best practice, help improve the Guide as necessary, and avoid all the unnecessary negativity which you seem to be continuing by saying, “Might as well use (something else)…”.


Awesome response to an emotive topic. I wish I could :heart: it more!


I’ll just add though on the packages not being updated that in meteor it’s a problem because many of those packages rely on older versions of some very important packages like aldeed’s simple-schema, autoform and collection2. It’s not obvious how to get those older packages, which still mostly work fine, to work with the newer packages.

For what it’s worth I did a combination of creating a cloaked version Simple Schema which pulls in the new one, and simply exposes it as if it were the old one, and selective updates to local packages (forks of various packages) to use the new versions of simple-schema and autoform.

That’s not a great way to have to do these things, but running two versions of simple-schema doesn’t actually work at all.

But for most apps I’m using newer packages like uniforms, so the problem is moot on those newer code bases. Eventually, on the one project I maintain which uses Blaze and autoform, I’ll move it to React and dump Blaze, which will solve my problem.

1 Like

I think you’re being too demanding on him. We’re all just mere humans, not some avatars of perfection. So yep, we are all biased and have our opinions and conclusions. That’s called freedom of thought.

On the other hand, I agree, that talking in that manner about open-source software is uncalled for, especially so regarding such a great and long-running project as Meteor. If I were working on Meteor team and have read similar comments, I myself might have lashed out way more aggressively…:japanese_goblin: :sweat_smile:

1 Like

Happily using iron:router and Blaze and many other stable Meteor packages that have been working perfectly as part of our production app since we started using Meteor in early 2015.

Even happier with the imminent release of Meteor 1.6 that will make our solution perform even better.

Still laughing loudly at all React/Redux/JavaScript flavour of the month framework/tool hipsters who have created their own software development hell whilst trying to convince everyone else that they are in paradise.

Farewell satya. May your next “party” not end with a hangover.

1 Like