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)…”.