Well ... interesting Meteor numbers in the State of JS

The problem with the data is not the sample size but the distribution of experience and usage of the technologies and how these variables are connected with the results. I, for example have a certain opinion about React, when I used it back in 2017. This “when I used it back in 2017” is the missing key to estimate the quality of my view on react. Now, since you worked in data science you might already have realized that the complexity of this topic cannot alone be solved using a quantitative approach but would require a mixed-method approach, which I think would make costs and efforts explode.

Edit: this is why I am writing the article, because I want to cover the qualitative side of things that the survey currently won’t (of course from a Meteor point of view)


What? so if you ask 1000 folks in Newyork to take a survey about their life satisfaction, you can generalize it to 7 billion people on earth?

I won’t argue about my degrees, there are several folks here who captured what I wanted to stay more eloquently.

Bottom line, I really don’t think this survey did Meteor justice and a big chunk of the participants probably never tried the product since 2015 and read few negative articles here and there.

Please tell @alawi :wink:

Again, I fully agree with you

Not sure if you’re trolling or unable to understand Statistics.

So for the benefit of this discussion I assume trolling and hence I won’t respond to this anymore

No I am not trolling and I don’t think you understand the results of this survey correctly.

You should bring your findings up with Sasha, so he can share his POV if he’s willing to do changes that you’re going to propose from a qualitative POV.


1 Like

I am as disappointed as any Meteor fan with the survey results.

But let us take a few steps back (and cool down the tensions brewing in this thread). :grin:

Seems like we are questioning the method of how the survey was conducted just because the results did not meet our expectations. This by itself is already flawed.

I am not saying that the survey is perfect. But we seem to be implying mistakes on the methods without any data backing it up. We are mostly making assumptions to give reasons to our expectations about Meteor. That seems unfair to @sacha and those behind the survey.


Fair enough, needless to say I’m not happy with the results and would like Meteor to get what it really deserves.

I apologise for the tension.

1 Like

I did Not intended to attack the credibility of the survey. I just wanted to say that the whole “state of Meteor vs it’s perceived state” can’t be covered in a quantitative manner and a mixed-methods approach is simply Not feasible. The article I am writing will clarify the missing pieces about Meteor to make people understand that Meteor 2020/2021 is not Meteor 2016.


I think your article is great, it is my arguments that came across as attack on the survey…and they are, this survey can be improved.

As far as I’m concerned, I’m not disappointed with the results of the survey. Maybe it’s just me, but I couldn’t care less for what other people think of Meteor, as long as I’m satisfied with it – and that’s exactly the case. Conversely, had the survey attested an outstanding popularity for Meteor, it wouldn’t have made me any happier.

I also don’t care about the popularity of the food I like best or of the music I listen, etc. My food won’t taste better or worse, no matter the changes in its popularity among other people. The same goes for the framework I use.


Neither do I rankly, I bootstrapped a business using Meteor and served me really well. But seeing Meteor at the bottom of those frameworks when I know for a fact it is superior to most of them doesn’t land well in my mind. And it mislead people.

Justin Bieber was immensely popular a while back. To me, that alone renders any popularity contest irrelevant for the next couple thousand of years. Yes, people are mislead all the time. No problem. :slight_smile:


Which one would you recommend in particular? I looked around two years ago when we started our latest project. Mainly because I had the feeling that MDG had dropped it. Yet I couldn’t really find an alternative that could get me as productive as I am with Meteor.


Will do… I was thinking about inviting him over for dabs next week actually… :rofl:


Hi Jan, I just read through your article. In general, I like it, but I think it still sounds a bit too negative, like “desperately” begging people to stick with Meteor. I don’t think Meteor deserves this. I believe it would be better to pinpoint some areas of improvement Meteor has and how they should be / will be addressed.

Just some ideas for this, based on my experience:

  • Meteor’s strongest USP is to offer a one-stop solution that offers a solid foundation to get apps up and running quickly. While this is still true in general, you quickly run into pitfalls once you actually want to use these, mainly because of the fraction that happened during the past years.
  • One example is out-of-the-box authentication. For React, I yet have to find a maintained (!) package that can be used for authentication. I’m currently using royGil’s account-react, for the lack of a better alternative. But this one is unmaintained right now, and it has quite some quirks I had to workaround in my own fork. Since I am not a bloody beginner anymore, this was an easy task to do. But if I put myself in the shoes of my “2015 me”, I would have given up. If you ask the community about this, the answer you typically get is: “Roll your own, it’s actually not that hard.”
  • Next example: i18n. The tap packages are more or less abandoned, and the recommended solution (universe:i18n) can’t even handle plural forms.
  • Next example: styling. Using SCSS works, if you know how to handle it, but you have to find a lot of workarounds if you want to work with existing SCSS libraries, e.g. you have to patch imports.
  • Other “all-time-classics” are file uploads and mobile support.

These are just some samples that come to my mind immediately. I think to get Meteor back to its former glory and really make it accessible to newbies, it is these “sharp edges” that have to be removed, at least for the most important basic components of an app. They have to play together in a way that “just works”, as it was back in 2015 when I got into Meteor.

Just my 2 cents.


@waldgeist thanks a lot for the review! I will Work on a revision tomorrow and hopefully get the article done by the weekend

1 Like

Actually these should be default:

As a professional

  • graph ql integration
  • scaling using redis oplog
  • complete ci/cd pipeline supported, deploy from GitHub actions
  • coming with meteor 2: HMR, tree shaking

I must agree with @peterfkruger - popularity in this survey should matter a lot less (though, kudos to @sacha, I think State of JS is a great snapshot of everything that matters in the ecosystem). I strongly believe that it would be a huge loss if Meteor was removed from the survey.

Gosh! There are actually significant positive findings that somehow have been missed in this thread:

  1. In itself, the fact that Meteor made it in the survey is a big deal. There are 20+ JS frameworks available and many are not even here.
  2. Satisfaction has actually stayed the same from 2019 to 2020, which is a good thing. Each year before it has been falling 10% or more year-on-year. So the downward trend has been stopped. Yay!
  3. It generates more interest than Angular (which has the whole Google machinery behind it, right?).
  4. Its usage has stayed almost constant in the last three years, not bad considering the chronic underinvestment until Tiny acquired it. It was basically on life support. Other frameworks that can be considered “sexier” and definitely don’t have all the past bad publicity (e.g. Svelte, Preact) have only a few percentage points over Meteor (3% and 1% respectively).
  5. The graphs used, though pretty, offer a distorted view. Look here for example:

Meteor’s usage has been the same or better in the last three years, while satisfaction was constant in the last two, but they appear as if in free fall. And that is because it is represented in relative terms compared to others, some of them new entries. The visualisation is misleading. Besides, I would argue that Hapi, Strapi and Gatsby have a certain degree of overlap, which muddles things further (it is often than H&G or S&G are used together in projects). One could say that Hapi and Strapi are better suited to the Data Layer section.

Riiight, now sorry for the wall of text and thanks for the patience :smiley:

Happy New Year everyone and happy coding!


Basically what the survey (and probably a lot of people here’s experience) says is that people who don’t currently use Meteor are not interested in learning it. Once you consider that reality, either you decide to focus on the current community and accept the fact that it’s not going to see much growth; or you start looking for solutions to change people’s mind.

Given everything we know about technology and human nature I wouldn’t bet on people giving Meteor a second chance (no matter how much it might deserve one) unless something drastic like a rebranding or version 2.0 happens. But even that might come too late.

But again maybe that’s totally fine. Not every restaurant needs to become McDonalds and try to serve as many people as possible. If Meteor can do a great job of solving the needs of a core community then that’s great! But yeah, the trade-off is that it’s always going to do poorly in this kind of survey.