I totally agree with you, @sacha, that without new users Meteor will not survive. At the same time, what kind of business can you make out of a… command line bundling tool?
The .NET Framework successful story tells us that there is a lot to gain by delivering a very opinionated system, together with tools, documentation, and professional support.
Also as a continuation of my post above, yes, a transformation and rebranding might be in order.
I still think that providing Meteor as a suite of tools, and with several recommended approaches to building apps, can make a good business. Why not have Minimongo + Tracker + Vue, while in another case you have Grapher (linked to Apollo, say) + React in another. Several boilerplates, documentation, so on.
And all that tied up with the bundling tool, and a nice Galaxy offering, can’t see how it would go wrong.
I want to thank you @sacha for your contribution over the years to Meteor, I’ve started Meteor with your discover Meteor book and also learnt a lot from VulcanJS. Furthermore, you’ve deep insight over the JS ecosystem with your stateofjs surveys, so your opinion has a lot of weight to it. However I’m finding it really hard to agree with you here.
A lot of tech stay in maintenance mode for a very long time, I recall people saying this for GWT/gRPC about 10 years ago and this tech still used today although certainly not growing. With that said, Meteor does have a tremendous room for growth, it started way early within the Node ecosystem and managed to adapt very well, furthermore the NodeJS ecosystem is still growing and attracting more folks from the php land and elsewhere and Meteor is great entry point.
The question is how to move forward and this where I disagree with you. I don’t agree with the assertion that Meteor needs major technical change or adopt react/graphql over blaze or else it will decline . As I said I’m a big fan of Meteor current flexibility and Blaze/DDP/real-time has it’s unique value proposition that Graphql/React simply can’t match. I think the real change need to be in leadership, community management and marketing. Over for the last 3 years, the framework was technically advancing (thanks to Ben heroic work) but there was zero investment in marketing/community management and it was preceded by poor PR communication in 2015 (the infamous we drop blaze post that scared everyone). Either way I think leadership is critical here to settle this debate and align the community going forward.
Meteor has a great opportunity ahead of it, and here is a potential strategy that could lead to growth with zero technical change (needles to stay technical improvement are welcomed specailly HMR and tree shaking).
Again I’m a big fan of your work, so thank you.
Bingo
Meteor had tried to piggy-back off the growth of other tools, like when they started to support Angular, React, etc. However, I don’t think it did much for them. The people who use React, Apollo, etc, are already comfortable, and prefer to, roll their own stacks.
Realistically, it would be a major footgun for Meteor to reject Apollo/React/Vue. So the only question is whether to continue support & development of DDP/Blaze. Since that support is already in place, it may be possible to do both.
Another new post, under a different thread, that fits very well with this perspective: Some Exciting Meteor News
I think it suits under this thread.
Edit: I originally pasted the wrong URL.
After reading a lot of the feedback here I can certainly see the case for the other side of the debate. And there’s certainly very good arguments for it. But I remain a bit skeptical… If MDG didn’t succeed with Meteor then I feel like just doing more of the same but with better marketing might not be enough.
Hopefully I’m wrong though. But I’d be willing to bet that when that “Meteor for GraphQL” does arrive (and I’m sure it’ll arrive sooner or later), it will eat Meteor’s lunch, and conquer a large share of the JavaScript ecosystem at the same time.
Their funding dried up, so they had to pull out/pivot. If they would continue with the energy they were working on before 1.0 release, any issues or shortcomings would simply be blown away with share brute force on all other fronts.
Now one could say that the issues with funding show the issue with technology, but I think this is more a problem of traditional VC models which expect return in few years and not in 10 years, or even they expect a profit and not just to sustain a development team.
Thanks for pointing out. Copy / pasted the wrong URL and didn’t even look.
But is the solution drastically changing the technology, or drastically changing the perception?
Grapher seems to be a wrapper for defining Mongo queries. Even though they strongarmed their way into the Meteor Guide, I think it’s incredibly niche.
Depends on which of those you think is easier/possible
I don’t disagree with you in that it’s niche. My point in that post was, if someone wants Meteor to work with Apollo (which seems to be all the rage these days), that that’s already possible, using the linking package with Grapher.
Really? That is your main criterium? 
The point is, changing perception isn’t just a matter of investing in marketing. I think changing perception is a very challenging problem and not one to be taken or looked at lightly.
Everyone in this thread is going to have their own perceptions of where to go based on their own needs and experience. I speak from my own point of bias.
The problem is less related to the perception than the lack of knowledge of Meteor. It is paradoxically very positive because there is everything to do for the construction of a positive image.
The fact that the founders never did marketing will help Tiny build an image and a perception.
True, Grapher does a nice job of packaging and documenting how to get set up. And to say it’s a wrapper was a huge overstatement on my part. If users like a graphql-like API that’s similar to Mongo’s query API (as I think of it), as well as relational support, and even an ecosystem of other tools around it, then that data stack is a good fit.
Grapher is awesome, my only concern is that even its creator stopped using most of its features. Which means most likely we’ll never have updates for that parts. E.g. it’d be awesome to fetch documents from network only when they’re not fetched with the same params/body without having to use apollo.
Any ideas on the best way to change this? does it require installing a local version and modifying the source or are their any flags available?
One idea that I would like to try on Meteor build system would be to not re-scan and re-evaluate dynamic modules if they are not changed.
I don’t think Meteor is doing this because I applied dynamic modules broadly in a huge app and the rebuild time still the same.
Would that be very hard? I think we could then cross the file watchers info with dynamic modules info and just re-evaluate the changed ones.