We have one production system (built in 2016/2017) that’s full Meteor and Blaze, including mongodb, pub/sub, accounts, and everything. And it works great, getting to ~100k users / month and still doing fine with a single EC2 node as an app server.
For our latest project however, I’m just using Meteor as a build tool, and use React with a REST API provided by feathersJS connected to a postgresql backend. It’s a great build tool, but leaving the comfy confines of the Meteor environment reminds me just how many problems Meteor solved years ago that the JS community is still grappling with today.
It’s 2020 and I’m still dealing with rolling my own accounts system. And reading tons of blog posts and articles about how to manage data access with a redux store and a REST API leaves me wishing for the simple pub/sub mechanism of Meteor that automatically provides local caching, expiration, record merging, sync, and optimized network transfers without a single line of extra code.
I have a serious case of javascript fatigue, and it’s annoying to see all these shiny new toys that everyone keeps talking about while basic functionality like accounts systems and data management are considered too unsexy for frameworks to focus on. Leaving complex data management optimization, or account security best practices, as an “exercise for the user” while touting a few tenths of a second reduction in time-to-paint benchmarks seems ass-backward to me.
So why am I not using Meteor fully? For me, it comes down to the ability to build a team. In 2016 / 2017, it was fairly easy to find JS developers who were experienced with Meteor. Now, it’s extremely difficult. Even previous developers that we worked with, when we get back in touch with them about working on new stuff, tell us they haven’t touched Meteor projects in years and have moved on to other frameworks. I’m scared to start a new project with Meteor and then be unable to find developers. Meteor is different enough (especially with the way pub/sub and reactivity works) that it takes developers, even ones comfortable with JS, at least a few months to really grok how pub/sub is different than REST APIs. While I’m willing to train new developers, I can’t be sure they’ll actually become good Meteor developers and unlearn the principles of the other frameworks they know.
That’s my biggest reason for “why not meteor in 2020” 
But to that, I’d add maybe a controversial idea: 90% of websites these days don’t need Meteor or even much of javascript. Before Meteor, I used Ruby on Rails to create static sites. And again, it’s amusing when people write React/node.js SPAs that are actually pretty basic static websites. Even many “advanced” websites are often primarily a static website with a few interactive bits that can be easily managed in a couple of limited scripts and AJAX calls.
In fact, for my current site, I wrote my prototype in Rails, because it’s an even better ecosystem, with well maintained gems for just about every problem you have, and only recently rewrote it in React when we better understood the features our early users needed, and decided that interactive and dynamic features were truly necessary and made an SPA worth the hassle.
So perhaps Meteor is stuck in an anti-sweet spot: those who chase shiny new features without regard to utility seem to hop to the latest greatest thing. And those who want a well-engineered full stack solution with a robust ecosystem choose Rails / Django / Java / etc and other older technologies for the 90% of projects that are little more than CRUD frontends to a big database. Meteor is stuck in the middle: not shiny and new enough (any more) to attract early adopters and momentum chasers; not old and established enough (yet) to attract the stable and boring developers.
The good news is that, IMHO, every framework goes through this transition. I think as long as the meteor ecosystem continues to grow, focusing on solving real problems that people have, then it’ll soon cross that valley and be seen as a stable, solid choice by the vast majority of developers that prefer to live a little further away from the bleeding edge.
