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

There are more aspects to that. “Heard of it > Not interested” at 63% does not mean 63% being disappointed with the framework. I’m not questioning the results, but I’m warning against drawing the wrong conclusions. While the findings of the survey are certainly interesting and useful to guide further strategy, I’m not sure if a call to rebrand is the right action.

What if they are not interested because they are simply too excited about all the other new stuff? What if the sample of the survey is indeed - and I would think inadvertently - biased?

For instance, SO 2020 Developer Survey shows jQuery as still the king of frontend, but in State of JS is merely relegated to a mention. (The fact that Meteor is missing in the most loved web frameworks is a different matter, but it’s also missing in the dreaded category.) In the same survey Gatsby, seems to be doing quite a bit better in terms of developer love than in State of JS.

Personally, I love seeing that the new owners are hard at work bringing the framework up to date, and giving it the TLC it deserves, having been left by the side of the road for years. The amount of work that went into it and in Galaxy in just one year is staggering, but that may have low visibility because a lot of it was long overdue. I’m sure there will be a time for developer PR and marketing as well.

Excellent comparison! Not everyone likes to eat at McDonalds.

4 Likes

This hits the nail on the head. This is survey is indeed a popularity contest and it is recommending the most popular frameworks.

Why?

It gives equal weight to those who used the tech versus those only heard of to draw the conclusion, and given Meteor PR history, it is really skewing the result for Meteor. So year after year, this survey will just rank tech based on popularity from the same selected small sample size (mailing list, twitter followers etc.) and then it will say avoid the less popular framework! How is that not misleading? If that is what this survey is about, then call it for what it is, and don’t recommend an avoid based on popularity ranks. Otherwise, improve the data collected, like who is actually using it and when it was last used, and use the opinions from the people who actually using/used the tech to draw valid conclusions.

Is a movie review from someone who never watched a movie of equal weight to those who watched it when deciding whether to see it or not? Meteor is a good movie for many, with unfortunately a not so good trailer. Or a TV show with an excellent first season, a poor second season, and a really good on-going third season.

Needless to say, Meteor has a PR issue since 2015, due to poor decisions by MDG and highly negative articles, hit pieces, by a very few but highly influential ex-meteor community members. Tiny is working on improving it, and it needs improve.

But is a popularity contest survey with a conclusion “To Avoid” labeled on tech a because it is not popular doing justice to the tech (Meteor and others) and the folks who are working on improving them? is it really leading people in the right direction?

I like that mindset, actually come to think about it, all the movies I like are not that popular either but they are surely good, at least for me :slight_smile:

1 Like

Is a movie review from someone who never watched a movie of equal weight to those who watched it when deciding whether to see it or not? Meteor is a good movie for many, with unfortunately a not so good trailer. Or a TV show with an excellent first season, a poor second season, and a really good on-going third season.

Haha this also remembers me on some TV-shows where community score and editor/reviewer score are so totally different sometimes. Often reviewers on RT write their season review based on the first episode which is total foobar but somehow it counts into the score :smiley:

2 Likes
  • Next example: i18n. The tap packages are more or less abandoned, and the recommended solution (universe:i18n) can’t even handle plural forms.

Did you give ostrio:i18n a try? It’s so lightweight and flexible that we are splitting our i18n files now into parts and pieces close to the Templates we dynamically import and add them dynamically so the initial i18n file only contains the most common labels, reducing bundle size even more.

  • 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.

File upload with ostrio:files is actually very straight forward, once you understood how it works, plus it’s well documented and @dr.dimitru is actively taking care of the repo and answers all issues.

Regarding mobile support I have to agree but that’s a fundamental issue with Cordova and something that could be discussed for future 3.0

6 Likes

Dear Meteorites,

Let me start with minimal background highlights:

  1. I’m using Meteor since v0.9, which means — for more than seven years;
  2. I released and maintaining 33 atmosphere packages. At least one of my packages always find its place in the “trending” section;
  3. Taking care of packages made by other fellow developers, like meteor-build-client;
  4. Aiming for A+ documentation and support over GitHub for all of my open source packages;
  5. Open source and its community are a big part of my life and business.

Here’s my opinion:

  1. Regarding survey — It’s indeed a popularity contest. There are big companies behind other frameworks that are leading the developer’s community. If Airbnb or Facebook switched to building their apps within Meteor — developers (and especially newcomers) would turn their heads towards Meteor;
  2. Regarding Tiny — Its marketing and PR impact is indeed “tiny”. I agree with many of you who mentioned that Tiny should start endorsing and featuring:
    • Projects build with Meteor
    • Consulting agencies and freelancers who provide development and support on top of Meteor
    • Success stories and businesses build on top of Meteor;
    • Services build on top of Meteor;
    • How’s about annual Meteor Awards? Get 2-4 categories, make developers and founders compete for the nominations. Let me help you with categories: [open-source project of the year], [success story of the year], [business of the year], and [Meteor consultant of the year];
  3. Regarding newcomers — Although development is a passion for most of us here, we still got to eat and feed our families. Are there many companies hiring for a Meteor-developer position? Are Meteor-developers paid well? What’s the reason for beginner developers to choose Meteor? “Fun and easy to use” tool won’t feed our families;
  4. Regarding Meteor’s application layer — Meteor does its thing and does it well. But you can not blame poorly performed Server when using reactive data sources on the static pages. Documentation should get updated instead of throwing killer-features at beginner’s face. Its use cases should get well explained. As developers, we still got to build micro-services on vanilla node.js and send performant requests to MongoDB using .rawCollection(). It’s a matter of choosing the right tool for a specific purpose. Meteor is superb for building and prototyping interfaces, it can be performant, stable, and serve on high-load, but this knowledge comes with experience;
  5. Community — Rather than having a vast community, I’m enjoying a strong community. Let’s keep it being strong!

:man_technologist:

15 Likes

so maybe Meteor should consider a rebranding or something

I don’t think meteor should change name, I think the idea of “Meteor” is still a good one, super fast prototyping, magic technology…

I think it needs to do a better job of being Meteor… right now, there’s too much friction. 3 lines of code, get you an user-login/user-signup and then meteor deploy to the web for free… this should be Meteor’s core story I think.

Right now, doing that is tricky… As a new user (new old user), unsure of the state of Blaze vs React templates… so not sure how to get an accounts user-join/user-signup quickly and doubt it can be done with 1 line of code if I want to use React. And no free deploy except for meteor-hero (I just found out about meteor-hero) but that still seems like a lot of friction.

Also integrating with MongoDB Atlas took me a few hours too! Friction, friction, friction…

@sacha I didn’t realize StateOfJS was a meteor app… is there an ‘About’ section? Would it be possible for you to throw a Meteor logo up in there? StateOfJS is the defacto front-end zeitgeist… I know when the results comes out it’s discussed at my company and probably lots of companies, congrats!

3 Likes

I agree with all of your points albeit this one:

Its marketing and PR impact is indeed “tiny”.

I don’t get how people are disliking Tiny’s contribution to the marketing and PR out of all things!!! I mean they have a monthly podcast, transparent communication (public Roadmap on Github, @filipenevola and @matthollingsworth on forums), success stories like any[dot]run and Meteor Impact [but this is partially Tiny and mostly @storyteller].

Surely, they can do more of the stuff you mentioned and other stuff people commented about here but marketing and PR has been actually one of the best things about Tiny compared to Apollo.

4 Likes

I agree, I also think Tiny is doing way better than Apollo in the marking/PR side.

I think nothing short of Elon Musk recommending Meteor would change those folks mind, the same year to year Not Interested 46% crowd that would vote, it is human nature, and I’m willing to bet that this crowd is actually a biased sample. They might be mostly large enterprise developers who are really not interested in full-stack all together, or those who read some of the hit pieces from 2015 and never gave the tech a try, but then the survey is probably missing the voices of a large chunk of the newcomers and bootstrapped businesses. That is my guess without the data to prove, but I think this is what is really going on here.

So no it is not Meteor that needs rebranding to satisfy a crowd that voice an opinion without actually trying the tech. It is this survey that needs to be fixed to give more weight to those who used the tech, which is a fair ask.

However, if this survey is to stay as is next year, then it is nothing more than a popularity contest, and it should be called for what it is. In that case, I’d argue it might be better to remove Meteor from that list and save it from the additional stereotyping and the negative unfair “Avoid” label. Currently, there are JS frameworks throwing millions of VC money to gain more popularity (Vercel/40 million, Gatsby/28 million), those frameworks are after e-commerce and they don’t have a proven business model yet, they are where Meteor was 6 years ago, and time will tell if they can manage to make returns on this VC money, I doubt it, I think those numbers are mind-boggling for any JS framework. Meanwhile, Meteor has passed that phase, (here is Meteor raising 20 million in 2015). It survived the exploration stage (where money startups fail, especially in Open Source, after the VC funding dries, like RethinkDB), it has a working business model, and it shines in areas where those frameworks lack, and I think a healthy steady and reasonable growth should be the goal at this stage.

2 Likes

I’ve been lurking on this topic since the beginning and I can tell this whole discussion somehow represents the state of Meteor.

On one hand, we have this community. Not only this forum but also GitHub. We even had a conference last year! And I really do mean we here. I’ve learned about Meteor on my first days at @vazco, back in mid-2015. It was great - real-time data working out of the box, shared client/server code, a ton of Atmosphere packages, and Discover Meteor for an introduction. And since then, I’m working with Meteor projects in production on a daily basis. Time has passed, new solutions emerged (and some of them failed), but up to this day, over 5 and a half years later, I’m still happily using Meteor. We even have projects started back then, being rewritten view by view from Blaze to React (and then to React again as we started too early, in late 0.13), adding a REST API, then GraphQL API… All of that without stopping the world, having multiple deploys a week. We are happy with Meteor.

On the other hand, there are people who had used Meteor unsuccessfully, moved to other technology for other reasons, or simply never tried Meteor at all. All of them have their right to do so. I recommended other stacks many times as well, when other technology suited the project requirements better. Having said that, we’ve never migrated a project off Meteor. Optimizations, splitting monoliths, adding other technologies, and using them together - that’s our way of dealing with the problem.

But that’s all from my personal, developer’s perspective. And then the client asks us about the technology we plan to use for this new project. And it happened a few times, that the word “Meteor” caused a long discussion and required a lot of assuring the client that Meteor is fine. Having a portfolio helps here a lot. But for some of them, who don’t care about developer experience or hype, acquisition by Tiny helped even more. And I am thankful for that because the lack of “official support” is sometimes more problematic than the lack of actual support itself.

To sum up - I’m not surprised by this survey result, not at all. I don’t think that Meteor needs a rebranding either - it could only cause harm. I really believe, that the only thing that could definitely help (I’m not sure about others), is a constant improvement and a vivid community. And we have both. There are better and worse days months times, but we are doing it. We are doing it.

17 Likes

Hey there, have update the article based on some of the replies and would ask you to re-read:

https://dev.to/jankapunkt/do-not-avoid-meteor-23kb-temp-slug-3727711?preview=2cd531d50bece506cc19493521eb69a91f693cc6940a567b08cee2f78aa01cb9ad75cc5c0b8780eae2c0d2b3c39f185b353f8fead1816a51d57977c2

Hopefully it’s not so much “begging” anymore :slight_smile:

4 Likes

From a purely psychological standpoint I recommend to avoid negative statements, even if phrased as a question. The combination of words “avoid Meteor” is maybe not the best choice, especially because one of the possible answers to a closed question is obviously YES – and then it looks really awkward.

What about “Is Meteor really to win a popularity contest?”

6 Likes

Title-wise I’d be more positive, like: “Should you start using Meteor?”.
Do not forget — 10 year anniversary (since first release) is coming next year! It should be special year for Meteor.

It isn’t only full-stack framework, it’s build tool as well.

We are using Meteor as build tool for many projects, it’s nothing like webpack, it’s just “set and go”, especially with tools like meteor-build-client nailing development of static websites.

9 Likes

I created some years ago an article about Meteor in spanish, it was titled "Why to choose Meteor (or not) for our next project?

Is my believe that you dont lead just with assertions and showing just why yes, but also why not. We shouldnt try everyone to use Meteor, is just not the right tool for every job nor the right tool for everyone.

I started with Meteor around 4 o 5 years ago and I knew little about JS (just jquery and some vanilla JS) it was the framework that led me to work on multiple startups around the world and to be able to be productive on my own startup being a solo dev. We should encourage stories of how Meteor could let newcommers learn, start and probably succeed with their startups, but also show the success stories of those who are doing it in a large scale, like Qualia.

So my take here is, why not start the conversation around ¿Why to choose Meteor (or not) for your next project?

Later we might even be able to focus on solving the why not’s.

Here is the link to my the article I was metioning. https://meteor.com.co/por-qué-escoger-o-no-meteor-js-para-tu-próximo-proyecto-fde84c4260e

5 Likes

Greqt article and quite complete I should add :smiley:. It’s clear that you did put a lot of work in it. Though I agree with @peterfkruger and @dr.dimitru that the title is negative. Perhaps something along the lines of “Meteor is the platform your startup needs… Or maybe not”, to follow the advice by @pmogollon

3 Likes

“Could Meteor actually be the platform your startup needs?”

4 Likes

Okay, too many choices for me, I already feel the pressure :smiley:

Please do a quick vote:

Proper article title
  • Is Meteor really to win a popularity contest?
  • Should you start using Meteor?
  • Why to choose Meteor (or not) for our next project?
  • Meteor is the platform your startup needs… Or maybe not
  • Could Meteor actually be the platform your startup needs?

0 voters

6 Likes

GraphQL isn’t a one size fit solution for everyone. If you don’t need to combine data from multiple source systems (eg MySQL, MongoDb and Neo4j) then it’s absolutely not needed and just adds unnecessary complexity.

But this is going OT

2 Likes

I finalized the artcle and will publish i this evening, unless there are major concerns:

https://dev.to/jankapunkt/do-not-avoid-meteor-23kb-temp-slug-3727711?preview=2cd531d50bece506cc19493521eb69a91f693cc6940a567b08cee2f78aa01cb9ad75cc5c0b8780eae2c0d2b3c39f185b353f8fead1816a51d57977c2

3 Likes

Just one last thing Jan. We can’t say ‘Why to’ (or maybe we can. I’m no english teacher but it sounds odd :smiley:)

I’d drop the ‘to’ and leave 'Why choose… ’

Which reads a lot better.

4 Likes

Thank you @marklynch I changed it. Only found some stack exchange topic: https://english.stackexchange.com/questions/210762/why-to-choose-or-why-choose

3 Likes