Let me preface this by saying I love Meteor, just like you. Been using it since 2014, and still do. While I fully agree with all of the great points listed above, I think from a marketing point of view it is also important to acknowledge the ways in which Meteor has gotten a bad rep over the years. As these are the things that are keeping people away, not the lack of shiny features in my opinion.
In my experience trying to convince agencies or other devs on using Meteor, these are the pushbacks I often get (directly or between the lines):
- Meteor is just a toy framework, nice for prototypes but not a solid base to build on
- Meteor is for people that are not really skilled programmers (this will only be amplified if we keep focusing on how “easy” everything is)
- Meteor doesn’t follow best practices (like not using NPM for installation, it just looks weird compared to other tools/frameworks)
- Meteor does not scale (I know we’ve beaten this to death, but it’s still a perception — and also a reason why focusing on the real time live data without acknowledging this concern I think will only backfire)
- It’s better to build it yourself (while I, as I think everyone on this forum, love the zero config and the fact that I don’t have to spend any time on bundling, deploying, devops, etc, I also think we are a rare breed among developers. A lot of devs like tweaking with this stuff, and feel that it’s the only way to get the best setup. So you will not convince those by focusing on the ‘magic’ of the zero-config setup. Maybe the solution here is to instead have detailed explanations of what the setup actually is, what choices were made and why. Like the specs section of a MacBook page; you can expand it or skip it, so people who want to can get into the nitty gritty, but they don’t have to.)
- Meteor is not secure (also a very old story, we all know the
insecureandautopublishpackages were there purposefully for ease of use and speed to get started, this decision has damaged Meteor’s image badly (comes back to the “toy framework, not for serious apps” perception). This is also why I insist we should not again focus on how “easy” and “fast” everything is, at least not without giving a lot more technical insights because it will only reinforce this existing perception). - Meteor ties you to Mongo which I’m not sure is a good database (often I have to work to sell Mongo as well, especially if other devs are more familiar with relational DBs).
- Meteor is hard to customize; it’s great as long as you’re using it as intended, but if you want to do something differently it gets really difficult
- You cannot/It’s difficult to host Meteor where you want (like in your own Docker container)
- Meteor requires you to buy in to their whole stack (this could be fixed by a “Make it your own” section on the website: choose your fav front end framework, Postgres instead of Mongo, connect a custom backend to DDP, … — by the way, there are a lot of the people doing very cool stuff like this here on the forums
. A cool way to reinforce this could be with cases; “Read why Company swapped X for Y to support use case Z”)
Also, I think it’s good to realize that the speed and ease of use apply to us in part, because we are used and familiar with the framework and its ins and outs. For newcomers, there will be a learning curve, likely making it less fast and easy to get started than what they’d normally use. Most devs probably also already have a set of tools they take from project to project (components, packages, Webpack configs, …), which already gives them a similar dev experience.
Please don’t hate me :), I am genuinely writing this to help, not to attack Meteor. It is also just based on my experiences, so it might not be representative. But do keep in mind, and I’ve said this elsewhere, that here in the forums is quite a bit of Survivorship Bias. Of course we are all convinced by Meteor’s features and benefits, but this is about convincing people who are not on the train yet, and everyone that left to come back.