This does more harm than good, and I recognise the same point as one made by @sacha in his article - with which point, despite my respect for the author, I disagree very strongly,
There is no ‘us’ versus ‘them’. The survivor bias term is condescending, sorry to say. What I recognise in most of the posts by “survivors” and in my own attitude is the desire to preserve Meteor’s status as a reactive, real-time full-stack framework. Whatever its components.
If there is a technology that needs to be left behind, I doubt anyone would complain much if there’s a migration path. What we want to avoid is Meteor whittling down to nothing more than an enhanced Parcel. I want to be building apps with Meteor, not stitching them.
I hope Tiny recognises the value in offering a full stack version, as well as separate components (e.g. the build tool), to grab as large an audience as possible.
I put survivor in quotes because the word here very loosely applies. The concept is however very applicable. Meteor as a platform has lost developers over time. So therefore, weather or not the word “survivor” is appropriate, those who remain will inherently have a bias. It’s 0% intended in any condescending way.
The post I made was simply my thoughts. The community at large, Tiny or whomever doesn’t have to agree or take them seriously. I was just presenting them as is. No offense intended.
I think maybe another aspect of the debate is whether you think about the issue in terms of doing what’s best for existing users (preserving Minimongo, maybe Blaze, etc.) or what’s best to gain new users (piggy-backing on the success of GraphQL, React, etc.).
An assumption that I should’ve perhaps voiced more clearly in my post is that in my opinion, there is no future for Meteor without gaining new users. So from my point of view, even if you consider Apollo/GraphQL to be “worse” than DDP/Minimongo (although of course that’s very subjective), that’s almost besides the point because we need to adopt these new technologies anyway just to be appealing to people outside the current Meteor community.
I totally get the idea that we’ll keep Meteor on the same slowly improving path and just let its ease of use and great developer experience speak for themselves, but sadly I just don’t think it’ll work. Outside this community, the perception of Meteor and its assorted technologies isn’t great, and it’ll take something drastic to change this.
It is this type of misconceived reasoning that led to the fiasco of New Coke, now an infamous cautionary tale in business about the perils of chasing popularity and tampering with a successful product.
From the beginning, Meteor has defined itself as an “opinionated framework”.
The Meteor community are those who share its opinions - yes, sometimes with reservations (I include myself in that category) but the level of agreement is far greater than the disagreement.
In our case, Meteor has provided sufficient flexibility to deal with our main difference of opinion (being able to use MySQL instead of MongoDB). Other people have disagreed over the view layer, and Meteor has provided the flexibility to use Vue, React, Angular and others.
Those who don’t agree with Meteor’s philosophy or need its functionality use (or should use) other frameworks.
Likewise, those who believe Apollo & GraphQL are development nirvana should either use Meteor with the Apollo & GraphQL packages or use Apollo & GraphQL standalone.
In all cases, Meteor must remain true to itself and the community who were won over to Meteor, incorporated it into their businesses and rely on it today.
Now with Tiny backing Meteor, I expect more attention to be given to PR, evangelism and keeping online documentation up to date - things that are seen by outsiders like heartbeats.
Us Meteor users have a big part to play by sharing our Meteor success stories outside the Meteor forum. More people need to showcase their Meteor-based solutions and stories of success at technical conferences and developer meetups and events - especially those that concern NodeJS, MongoDB, MySQL, Databases, IoT and WebApps in general. I previously posted about this here.
Well, here in Sydney, Australia the most common reaction I get when I tell other IT people that we use Meteor is: “Meteor? I’ve never heard of that”. I then tell them how much it has done for us.
The upsettig truth is that, yes, Meteor has lost users over the years. However, having witnessed the neverending debacle when Blaze was dropped in 2015, it looked like there was a succession of bad decisions afterwards. Instead of marking the moment as a point of transformation in the life of the framework, MDG made it look, mostly through non-action in some cases, non-communication in others, as if the ship is being abandoned.
Then at some point they simply decided that Meteor the framework is not worth investing in. The rest (FUD, influencers leaving, etc) followed.
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).
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.
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.
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.
