To be "The Javascript App Platform", as displayed prominently on the Meteor homepage. If you build an app with Javascript, MDG want you to build it with Meteor. In order for you to do that you need to trust that you can use the tools you want to, and derive benefits from the fact that the stack is designed to work as a single platform. So if GraphQL is where it's at, it makes sense to design a place for it in Meteor.
Well yes, that's their general goal, but hasn't the developing React stack already won on that front?
It frankly seems they at least believe it has, as it appears their plan is to take it, bundle it together under one name and re-implement some parts.
The question is then, why would anyone on the React stack, which has become so popular, switch to Meteor? The stack of libraries Facebook has already put out there (not to mention third party libraries such as Redux) are designed to work together, and do so easily and very well - people are familiar with them and already using them.
I suppose the only dimension on which they could coax people over from the existing React stack, Relay in particular, is by developing its feature set faster and better than Facebook can. For what it's worth I think it's a good thing, I just find it pretty intriguing if that's their play - going up against the popular tide and basically directly competing with Facebook on bundling together their own libraries. Will be great to watch their progress!
Has it won? Where can I go and write `react-stack create my-new-project` and get a guaranteed working integration of the various elements that make up the stack, including a working server environment, pre-installed and configured database, and all of the other inbetweens that come with Meteor (such as DDP, livequery, Tracker, Blaze, ReactiveVar, etc)?
The "React" stack has certainly been an up and coming potential competitor for Meteor, but until Facebook or someone else actually shows signs of preparing the kind of integrated development experience that Meteor ships with out of the box, I don't think it's really similar. So that's what they're doing: tying together the best of the Javascript ecosystem, which happens to currently include a couple of projects by Facebook, into one cohesive whole that "just works".
Is "react-stack create my-new-project" really preferable to something like "git clone git@github.com:react-stacks/react-firebase-template.git my-new-project" ?
I'm sold on the latter, since often enough I'll customize and publish my own tweaked templates as I become enamoured with different tech.
The point is that Meteor will be handling the subscriptions side of things, the reactivity. There's a near-endless amount of work there to get it right. GraphQL and Relay don't even have an interface for subscriptions yet. The plan will likely be to make Meteor's actual concrete system work with the interface they provide by specifying a few lines of code. Facebook and React likely won't do much to address the implementation of subscriptions, which may very well be a larger undertaking than all of GraphQL itself.
In addition, what Meteor is about to build here is a long time coming. It's something they have been thinking about in one form or another for years. What I'm referring too is a purely webserver-based interface for subscriptions that doesn't take advantage of any special database features, and is therefore database-agnostic. GraphQL happens to come at the perfect time as the solution to supporting multiple databases. And as the only open source full stack reactive solution worth its salt, they know the challenges of building this solution better than anyone.
Their current solution, Oplog Tailing for Mongo, has been on the chopping block for a while since it doesn't scale far enough. They've experimented with PostgreSQL triggers. And now they're drawing from all this experience to harness GraphQL types to build the best-in-class interface for anyone to take on full stack reactivity. My guess is it will likely not be as performant as direct Mongo oplog tailing, but will allow developers to customize it to make it faster where you need it, which is something we've never been able to do. In addition, if the low level interface is good enough, it will likely result in many packages that provide for specific optimized reactive/subscription scenarios.
So no, the "React stack" has not "already won" on this front. Subscriptions is a big problem with many different solutions. Likely what Facebook has can't be used by anyone but the largest of companies. If Meteor both provides a decent database-agnostic subscriptions interface + an API to customize it for performance, Meteor will likely have done what nobody else has or is willing to do.
I'm a React fanboy, and use it and React Native in production on some pretty large apps. However, Meteor adopting React (and related tooling) still has merit, as to build those projects required me to wire them all together, enforce convention for the other developers using it so that we didn't try to use the tools in ways they weren't intended, and work around the various issues that crop up when doing Unviersal Javascript. Meteor can solve all of these, and can market themselves as that integrated solution. We all win, in that case.
Meteor doesn't need to steal any developers from vanilla React, because React has negligible share of the addressable Web development market. People will start on Meteor because it is easier and then they'll stay on Meteor. I doubt vanilla React will catch up with Meteor in marketing or ease of use because Facebook isn't hungry in the same way MDG is.
