I understand, but two points in respond to that:
The stats says the 50% heard but didn’t even try so they don’t even count as beginners.
Things I like the most of MeteorJS are:
I only build some small/medium websites, those are enough.
In the comparison
Years of experience breakdown for developers who picked “used it, would use again” for a given option.
Has Meteor the highest rank among devs > 20 years experience (even if the absolute value is low with 9%) and the second highest ranking for devs with experience between 10 and 20 years.
This is something that stands more important to me, than seeing it in the “avoid - low usage, low satisfaction” corner.
Considering this fact, I wonder how a tech gets this label / summary if well experienced devs used it and would use it again!? This raises concerns about the way they evaluated the poll.
As already mention (and reflected in the poll) the biggest issue is IMO the low public relations / marketing of the framework.
Edit: Most interesting fact:
Most disliked aspects of Meteor among developers who picked “used it and would not use again”.
Diminishing momentum/popularity
compared to
Most disliked aspects of Express among developers who picked “used it and would not use again”.
Clumsy programming style
That’s an interesting catch as well, indeed it seems to have the highest ratio of experienced developers relative to beginners.
Exactly.
The sad part is that this is a relatively low-hanging fruit compared to the amazing technical work that has already been put into Meteor over the years.
For example you could rename Meteor something like “Apollo Build” or “Apollo Kit” and brand it as an all-in-one back-end for GraphQL apps (basically what I’m trying to do with Vulcan). I can understand MDG not wanting to split their focus, but it’s still a little bit sad to think about what could’ve been…
Exactly, I made similar suggestion to rebrand Meteor to Apollo Build in thinking about Meteor 2.0.
Technically, the closest thing that comes close to Meteor, at least in mind, is Uber’s fusionjs but even that doesn’t have Meteor’s maturity or the feature list.
That’s interesting indeed. I’ve been thinking for a while that Meteor’s main problem is not the tech, but the marketing. There’s no clearly definable value/prop. It just has well thought out answers to problems experienced developers know they’ll run into. It’s an interesting problem to try and solve.
(Also, Meteor needs a better story on Windows!)
I for myself understand Meteor as a framework for apps, where realtime multi user interaction plays a crucial role. I don’t see other solutions that come close to helping me realize projects / apps with this role in focus.
Of course it offers way more but this is some kind of value proposition of the framework that is the reason why it fits my use cases perfectly.
I know it’s been almost 2 weeks, since your post @sacha , but I feel we are at an inflection point.
And if not handled well, Meteor will slowly fade away – likely following Galaxy revenues. Is MDG’s marketing budget the problem? If so, the community needs to step in (there are many ways to do that collaboratively) – combined with stubalio being gone (and he had left the forums a while back to focus on Apollo) I am getting antsy about all of this.
I also feel that people are getting afraid of JS frameworks (hence express is #1 – which is awkward)
Well, my personal solution with Vulcan.js is to develop a new framework on top of Meteor that aims for the same goals at the “original” Meteor but using a more modern stack. The idea being that everything Meteor-specific is then abstracted away, so you only get the benefits of the technology without being weighed down by Meteor’s current bad image too much.
I can understand if that doesn’t work for everybody though, Vulcan is fairly opinionated and might not be suitable for all Meteor developers.
Thanks @sacha
I applaud your effort in the loudest. My concern is that
In fact, while React has wind in its sail it seems to be slowing (VueJS is an example of competing framework) and I believe the community now realizes that VirtualDOM comes with problems (in this testbench redom is either similar or better – sometimes much better – in many tests: https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html [filter by frameworks for an easier read])
Also, I am wondering if GraphQL is as hot as it used to be. In our case, we have custom pubs and man are we more efficient for reactive pubs.
If I look at the atmosphere packages we are using, they are very few (redis-oplog being the prominent one). So maybe the history of Meteor is hurting it, people are not realizing that the framework moved on to work with ES6, NPM packages, and dynamic loads (and almost all major UI frameworks)
You hit the nail on the head there.
I haven’t been around Meteor long enough to speak of the transition, I was really in when MDG was announcing that they were dropping support for Blaze (what a marketing fiasco!). Maybe we need to be active contributors? It would be in MDG’s best interest too. How about a MWG (Meteor Working Group)? We meet to discuss this and other issues, bring it up with MDG and have a concerted one-voice to the community. Right now … there is NO voice.
It would be a much better if such a working group is more guided and organized by MDG. Active organization of your community is IMO a crucial part in open source leadership and it brings good PR (public relation, pull request, pizza rounds etc.) without a lot of expensive investment into a ad campaigns.
Great idea, can you call them and let us know 
@thea no longer responds and @sashko is gone. Who do we reach out to?
If there is interest, we can start a new thread … if not, then it’s a sad state of things
It would be great if someone from MDG could take a couple of minutes from their schedule and write a few lines here about the general plan they have with Meteor right now and where does it fit alongside Apollo. Meteor’s roadmap in github discusess technical matters, but on top of that, a broader view from MDG themselves would be much appreciated. Even if there is no apparent plan, the transparency by itself itself alone would go a long ways.
I can’t speak on-behalf of MDG management about the future of Meteor, but I can say that:
Regarding where Meteor fits alongside Apollo, let’s go back in time a bit …
As many of you remember, one of (if not) the biggest complaint about Meteor way back when, was its lack of support for data stores other than Mongo. This problem was constantly referred to as one of Meteor’s biggest shortcomings, and was continuously pointed to as being one of the main reasons why organizations couldn’t adopt Meteor. For those interested in this backstory (and other fun parts of Meteor’s history), take a few minutes to run through the old Meteor roadmap.
MDG knew this was a problem, and started to invest time into figuring how to best untangle Meteor’s dependency on Mongo. Initiatives like https://github.com/meteor/postgres-packages came out of this work, and while promising, it became pretty clear that the amount of work needed to build one-off integration packages like postgres-packages, for many different data stores, was not something MDG could invest time into doing. There had to be a better way to open Meteor up to be usable with any kind of data source, while at the same time retaining a lot of Meteor’s awesome real-time goodness.
While MDG was working on this problem, GraphQL was announced and open sourced. The core ideas behind GraphQL weren’t new, and at the time MDG was exploring various data layer options, including solutions based on graph theory. But along comes Facebook with not only a fully tested and battle-hardened data graph specification (that can work for just about any type of data layer imaginable), but they’ve also open sourced a javascript based reference implementation, and are actively looking for people in the OSS community to help drive it and the spec forward.
We’ve all heard of the benefits GraphQL brings to the table, and MDG was quick to realize those benefits could greatly improve their current data layer issues. They jumped on-board with Facebook almost immediately, and the idea of Apollo was born.
It’s important to remember that one of the other biggest complaints about Meteor at the time, was that it was a monolith. People couldn’t incrementally adopt just the parts they wanted to use, without having to bring in pretty much everything. Needless to say, this was a showstopper to wider spread Meteor adoption, especially for larger organizations with significant technical investments and infrastructure already in place. One of the founding principles of the Apollo data layer (which again was conceived to help address Meteor’s data layer issues), was that it would absolutely be incrementally adoptable. With this principle in mind, MDG started working on its new Apollo data layer, engaging anyone it could find to help out, in the open source community.
While MDG was working on Apollo, they realized that most of the people who were working with Apollo and adopting it in their OSS projects, and at their companies, weren’t using Meteor. These people wanted to leverage the advantages of GraphQL, and needed an incrementally adoptable way to get started with it, which Apollo offered through various tools and utilities. MDG was one of the first companies to jump on the GraphQL bandwagon, and with its extensive background in dealing with data layer issues through Meteor, was able to build the right tools at the right time to really kick start an amazing amount of traction in the quickly growing GraphQL space. That traction has snowballed to the point where MDG (Apollo) is now one of the primary leaders in the GraphQL space.
So what does this trip down memory lane have to do with how Meteor fits in alongside Apollo? Everything 
. While Meteor and Apollo were both created by MDG, and Apollo actually grew out of Meteor, it’s important to note that one doesn’t supersede the other. Does your company have a massive existing technical infrastructure, and want to make it easier to pull data from hundreds of data sources using a common schema, gateway and query language? Apollo and GraphQL are definitely worth checking out. Does your company want an all in one solution for developing/maintaining a custom real-time logistics app for your entire organization? Meteor is good to go.
Meteor is still hands down the best all in one solution for building modern real-time apps quickly and effectively. I (and other MDG team members) use it every single day, for both personal and commercial projects, and would be very, very, very sad if it didn’t exist. Thanks to MDG’s founding members, and their understanding of the importance of open source, we’ve all been able to work with this amazing platform, many of us for years, for free. And thanks to the nature of open source, as long as the Meteor community doesn’t want that to change, it won’t.
@hwillson I’m so glad with your response. I’ve seen those topics and I agree that Meteor is pretty much tied to Mongo atm. That’s not a bad thing though and at the time most of us agreed with that aswell. I love how well it integrates and it actually made me like Mongo aswell. I do understand that in larger organisations people require this spider like structure where many api’s are combined into one facade. However I still feel that this could have been done with Meteor.
It felt to me that Meteor was moving towards the broader community by allowing NPM packages. Why did that stop?
I totally understand that Apollo has become very popular and that MDG is putting a lot of effort in making it even better. It feels to me however that the whole discussion we have is not about Meteor’s features, but more about vision. It stopped. There is no sign of where MDG wants to be in for example a year from now, what it wants with Meteor and how it stands next to Apollo.
The most frustrating part is that while I’ve noticed that even though the Repo is still maintained, there is no communication on the forum, no updates being made to the documentations and even the website links on meteor.com lead to Apollo.
We as a community need a bit of guidance. Because if I know that the plan is to untangle Meteor into plugins allowing for incremental adoption, I would be happy to roll up my sleeves and help out as much as I can.
Here’s what I ask. I don’t expect MDG to radically change back to focus on Meteor again (would be awesome though haha). I do expect community involvement. Regular blog posts, occasioneel Twitter updates, Github activity and most of all, replies to emails. I have sent an email regarding this topjc, but did not receive any response yet. Painfull.
With all of this said, I want to repeat that I’m very very happy that someone is replying and that you took some time to clarify things. I’m not unhappy. I love Meteor and I love what MDG brings to the community with both Meteor and Apollo.
My two cents:
First of all let’s keep in mind that MDG needs to make profit, it’s a company that is betting on Apollo and GraphQL to achieve this.
It didn’t really work out to make enough money out of Meteor. Galaxy is just a middle man and it’s too easy to cut that one out and run your infrastructure yourself, at a much lower cost (my company has done this with a significant decrease in cost).
So it still needs to figure out how to make money to pay the bills and deliver value to their shareholders (founders and VC’s).
If we keep this in mind then a lot of this makes sense all of a sudden from their POV. We might not like it, but MDG’s focus aren’t the developers and small companies like ours with less than 5 developers. They aim for bigger companies and hope to solve their pain points.
Like others mentioned I do believe that it once went in the right direction, opening up to NPM packages and giving power to the developers and the community. That seems to have come to a slow down or even an almost stop, hence the radio silence as noted on marketing activities but also forum activity.
At the same time it shouldn’t wonder anyone that as a consequences the feedback delivered by the 2018 polls are devastating. To me the most important feedback is that Meteor is going down the drain. Both in importance as well as in progress.
Lastly, we’re still using Meteor and Blaze at my company. We have no reason to switch to anything else now, our code base is too big and there is way more work than developers.
I just hope that things turn around for the positive again as I have the “angst” of Meteor dying with MDG.
I think that’s overly negative. While surely Meteor is not receiving the same funding/attention but I think it’s being held at higher standards then all the rest of JS framework, I’ve been watching the repos for other open source frameworks and they’re as active (if not less) then what is Meteor today.
What the VC funding unfortunately did (as it does to a lot startups) it created a community that is dependent on the core specialized salaried developers. I keep hearing of businesses that running viable business on Meteor yet they (a) run from Galaxy to save cost (b) contribute no PRs or close issues on Github. If companies managed to achieve success via Meteor, then what I don’t understand, why they don’t reciprocate and invest in advancing the framework? Like any other open source frameworks, the longevity of it is largely driven by the community support, contribution, value proposition, attitude.
I mean how MDG (now Apollo) are going to die when they’re leading the most advanced GraphQL framework? that’s not rational fear, they did the right thing as a business to pivot to GraphQL.
Also, I don’t understand why a survey is providing consultation advice by stating to avoid, it should just stick to providing stats and let people use their judgment. All it did is reinforce the majority stereotype, the 50% who judged the framework without even trying it.