The ease of getting up and running, the ease of tools, and the ease of deployment. On no React stack can you (and in the future this will be more simple) run
And start coding JSX, ES2015/2016 immediately. There is a non-trivial amount of boilerplate and configuration you need to do to get this working my hand, and while it can provide a greater level of control, it undoubtedly adds to the overall weight of code you need to maintain.
Then hypothetically after some time of development, do
meteor add-platform ios
meteor add-platform android
meteor add-platform desktop (this is theoretical currently, but there exist packages which do exactly this)
And have Cordova iOS and Android builds, and an Electron desktop app. Then in a few weeks, do
meteor deploy
and have a fully monitored application up and running on AWS with Meteor's monitoring and deployment tools. Meteor's play is in the ease of these tools. It is absolutely non-trivial the amount of glue and knowledge you need to create, understand, and maintain the current (and ever-rapidly expanding) Javascript toolchain.
This announcement touches on one of their most thorny issues of being tightly coupled to Mongo. Adding this abstraction layer allowing any UI and any data source is Meteor's ticket to the masses.
When thinking about Meteor's value proposition, it's been neck and neck between what you're saying (which is that of a "universal build tool") vs. it's full stack reactive subscription capabilities. Both of which have been Meteor's 2 most important features.
That said, on the build side of things Webpack and Babel have been giving Meteor a run for its money. It takes more work to build your app with those tools, but it's a lot less work than it used to be using plain NPM, and you now have a lot more customization than in Meteor.
That's why doubling down and continuing the thought of full stack reactivity is so important to Meteor. I'm so glad to hear that they have suited up to upgrade their reactive server-side parts. I hope they put a lot of resources behind it.
If interested, here's my take my take on what "Reactive GraphQL" means to Meteor developers:
I think I get your point, and while I haven't done much with meteor since a few weeks after it was first announce, I recently started a couple react.js projects using jspm. I'm not sure, yet, if jspm is ready for prime-time, but getting started was as simple as:
Well said! I actually think the community has done a ton of work on Electron and we will see the desktop option soon too.
This announcement is exciting on many levels and I think some of the unspoken bits will be interesting later too. I hear they are working directly with people at Facebook on this project.
It's better to understand it as the cathedral to npm's bazaar. Everything down to the third-party packages is cohesive and never needs any wiring up or glue-code.
To be fair to the GP, this view-layer-independence is very new, only officially supported since summer. Very reasonable to see it as all-in looking any time before.
Each successive post of the recent set from meteor just seems to be bringing it further towards resembling the features of a GraphQL > Relay > React stack - in fact actually using React, and now it seems, GraphQL.
This is great because the promise of a stack like this is very exciting, but I am left wondering what is meteor promising to bring that isn't just bundling some modules, and re-implementing Relay?
I can't see anything in the list of what we are planning to build that isn't already offered by Relay, or on Relay's roadmap.
Not that a different implementation isn't a great thing, competition is always advantageous, but my understanding is that Meteor is a for-profit company whose product is their framework - it seems quite odd therefore that their plan for that framework appears to be to just piece together and/or re-implement an already-existing, well-used and well-known stack of completely open-source libraries, that aren't at all difficult to piece together as it is. What's their strategy here?
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.
In the end it's about the UX from Meteor's side. If they can take all these technologies and make it very easy to work with (without all the annoying boilerplate setup, etc) then it's a big win.
Is Reactive GraphQL even specified? I thought that in the current state GraphQL only defines single queries (snapshots) of data, and not continuos update notifications. Forgive me if I have missed it - I have not followed GraphQL/Relay apart from a very basic look at it.
Without having an open specification Meteors implementation might end up completly different or incompatible to other (Reactive) GraphQL implementations.
Despite that, I think that implementing a reactive GraphQL backend will be very hard, and it would only work good if all of the sub-data-sources that you use in your backend support reactivity (subscriptions) as well. If they do, then you have to subscribe to all possible data sources that are mentioned in the query, and update the current state when one of these changes. If the update requires you to fetch an additional data source (e.g. you must fetch other indexes of data which are provided by another source), you must even dynamically subscribe/unsubscribe on updates of other sources.
And how can you provide traditional REST APIs (or even query-based GraphQL endpoints) as reactive endpoints? The best you can do is probably implement polling (rerunning) the query on the backend over and over.
The idea of changefeeds / subscription cursors has been around for a while now, especially in Meteor. I doubt it'll be that crazy to add reactivity to graphql queries when compared to what Meteor is already doing w/ subscriptions and DDP.
That doesn't really contradict my statement. I agree that the feature is already there in Meteor (only with another query language), and that it's also supportable by RethinkDB, Firebase or any other backend/db which supports subscriptions. By what I meant is that it requires support for subscriptions all along the chain, and this is not supported by legacy REST/GraphQL/etc. APIs. The lack of alternate DDP backends besides the MongoDB one (and of course the creation of custom subscriptions) seems to confirm this.
I am sure they could now update their query language to GraphQL instead of MongoDB queries by adapting and extending the existing system, but I don't know if thats currently the biggest problem for meteor adoption or only something that is nice to have for some GraphQl/Relay fans (which still might be using these directly anyway).
I'd recommend rebranding and a big-bang launch. Enough people were put off by meteor that incremental improvements don't excite. Kind of the opposite of the boiling frog thing.
Offline support is tricky because each app needs to implement what happens in the case of data conflict. Meteor already has the groundDB package that allows for offline support in local storage. I would imagine you could implement a read only option into local storage once they release reactive graphQL.
We have some thoughts about how the new invalidation system will make offline a lot more feasible. In pub/sub based Meteor apps you would need to reload all of the data if you took too long to reconnect, in the new system you will hopefully be able to get just the diff after a much longer reconnect gap, or possible indefinitely depending on implementation details. This is because the app server doesn't need a copy of all of the client's data anymore.
Is anyone playing with GraphQL outside of js? Am interested in using it for a project at work and wondering what's it like in something lower like c/c++.
I've been playing with a scala implementation called sangria (http://sangria-graphql.org/). The type safety of Scala has really been helpful for refactorings and creating the schema. I can't imagine the mess I'd have been in if I'd have used JS.
The ease of getting up and running, the ease of tools, and the ease of deployment. On no React stack can you (and in the future this will be more simple) run
And start coding JSX, ES2015/2016 immediately. There is a non-trivial amount of boilerplate and configuration you need to do to get this working my hand, and while it can provide a greater level of control, it undoubtedly adds to the overall weight of code you need to maintain.Then hypothetically after some time of development, do
And have Cordova iOS and Android builds, and an Electron desktop app. Then in a few weeks, do and have a fully monitored application up and running on AWS with Meteor's monitoring and deployment tools. Meteor's play is in the ease of these tools. It is absolutely non-trivial the amount of glue and knowledge you need to create, understand, and maintain the current (and ever-rapidly expanding) Javascript toolchain.This announcement touches on one of their most thorny issues of being tightly coupled to Mongo. Adding this abstraction layer allowing any UI and any data source is Meteor's ticket to the masses.