Maybe thus far. But that’s like saying that because our servers use primarily C, it’s all about C, instead of the the HTML rendered to all the browsers that load websites from those servers. Even if this was before HTML and the browser existed (just as Relay barely exists)–where it’s all going is to provide the best interface for humans to use. And given that GraphQL and Relay is all about data and matching its “shape” to that of the UI, we’re talkin about its role in the UI. I mean that’s why they talk all this hubub about how you can craft data requests in the “shape” of your components, in the “shape” of what your UI actually needs. So, what you’re saying is they are using GraphQL between server to server endpoints within Facebook?? And that’s the main goal of all of this? Even if it started out that way, it’s looking like it will get a lot more shine in the UI where everyone can see it. In general, I think that’s why javascript and UI frameworks (and the browser where you can see the source!) have been driving innovation–when people can actually see things (vs are hidden under the hood), it changes everything. It gets eyeballs, and therefore adoption, collaboration and therefore more iteration.
Relay will shine regardless of whether one is more important than the other. Relay is also a key piece for which we’re waiting to see how it pans out. It’s missing things that Facebook says are part of their roadmap: subscriptions and client cache/state (Redux stuff). There’s likely more. They hired Dan Abramov, creator of Redux, after all–Time Traveling in Relay too??? What are we waiting for regarding GraphQL (besides the implementations we’re supposed to do ourselves)??
In my mind, Relay is C - the implementation - and GraphQL is HTML - the actual data format that is passed around, which is the important part. Relay currently won’t help you when you need to load GraphQL data in your native iOS app. I think GraphQL is the thing that could truly build up an ecosystem of great tools, the client-side libraries for it will come and go the same way they came and went for REST.
Interesting point. I guess that’s why we need to build Meteor’s “Relay.” In my mind, this done right is a consistent “Relay” (or other) interface in browsers, in iOS, in wherever. I’m also not 100% sold on Relay itself, given its verbosity, boilerplate, etc. And perhaps you aren’t either–because your recommendation to MDG is that they make their own Relay-inspired interface??? eh? eh? eh?
In short, something tells me we are talking about the same thing. Perhaps none of Relay is actually used, and it only serves as an inspiration. Or, perhaps we build a wrapper on top of Relay. The wrapper that Meteor provides makes for a simpler interface, but allows for you to dig down and use the lower level Relay API if you really need. I see the same with GraphQL in general–Meteor should generate GraphQL machinery for Mongo and our pubSub, and if you need to optimize specific queries/mutations direct access is provided somehow (oplog-based LiveQuery could even be still used in the V1–just to get something out sooner); but if you don’t need direct low level access to GraphQL types and resolutions, you don’t need to concern yourself with it. In both cases, we get to take advantage of larger ecosystems, and developers with GraphQL or Relay skills can make use of them within Meteor. etc etc.
The specifics of how we execute this–yea, I don’t know yet. Relay may be worth throwing out like you seem to be implying. But what Relay accomplishes likely will be our first class priority. In conclusion, MDG doesn’t want to fight back on the React view layer front, but thinks a better battle may be on the pubSub/Relay front? Great decision, how can I help?
I like that Meteor is official supporting Angular and React. I think it’s good the dev have to option to decide which front-end framework they are most comfortable with. Right now, I’m more comfortable building app using Meteor + Meteor-Flux + React.
Well, to be clear, and the reason I keep saying things like “Relay(-inspired)” is because it’s about what Relay accomplishes, not the brand of any specific product. And without an exciting new tier on top to create using GraphQL (like Relay), GraphQL would be worthless, or at least less of a big deal.
If we can do Relay better than Facebook, we should. If we can use Relay under the hood to our benefit we should. It comes down to specifics that developers can agree on and discover after the overall goal is pinpointed. But my perspective doesn’t change: it’s the interface into the view layer (what Relay has pioneered) that makes all the difference to application developers. Even if GraphQL is the most important tool used by “library/framework developers.” I mean that would only make sense if framework developers use GraphQL to create a bunch of competing Relays.
Either way, it’s all following the river to the ocean, and the ocean is the view layer. GraphQL is the river. So sure, from the “framework developer” standpoint it’s all about GraphQL, then why aren’t we using it to build a competing Relay already (like Om Next has) instead of basically recommending people use Redux?? It’s obvious all “single source of truth” features should live under one roof with a consistent succinct API. Domain State + UI State + Time Traveling + Meteor’s special sauce: subscriptions. And it’s not obvious whether Relay should be out of the picture as something we use yet ;). My perspective is not until React Conf at least.
Hi @arunoda, I’m following Mantra. Regarding State Management, I’m a bit confused. The use of “State” seems too ambiguous to me. Router states seems to be Application State, and then we have Data states, UI states etc… I’m not too sure the correct terms here… but should they be conceptually separated ?
e.g. an App with options/branching/user decisions, for simple use case, router and url may be sufficient for flow control, but for App with more complex states, I’d rather use FSM to manage the flow control/switching. Does that count as “State” management in your scope?
[quote=“dfischer, post:132, topic:16100, full:true”]
I’m a bit confused, so is Blaze going to be actively maintained and improved upon, or just left around and used for guides?
[/quote]Hi @dfischer, you might get a MDG response, but incase not, this comment just yesterdays seems to suggest the latter:
We can only guess what MDG means by “maintains” above.
My guess is “maintains” to MDG right now and in the context of Blaze means they’ll keep Blaze under their control and nothing else. Not fully open source it. Not allow the community to drive the direction of change or fix bugs. Hopefully this is a temporary state, but it could very well be permanent.
An adjacent guess is Blaze will be frozen as it is today and depreciated slowly, not dropped outright, only due to the: lack of proper Meteor React/Angular integration generally, lack of proper Meteor-integrated package coverage even at the basic level in some cases, lack of written guidance for Meteor React/Angular, and finally legacy Blaze customers and developers.
This comment seems to suggest Tracker and Blaze as stand alone, open sourced, community driven projects are a possibility (fingers crossed):
I think Tracker and Blaze would be a great contribution to open source by MDG.
If I may ask a stupid question, and coming late to the party it might be.
What is the reason to drop Blaze for Angular/React? Why cant Blaze be the React/Angular replacement? From my 2 weeks of tinkering and evaluating Meteor i find it totally awesome! What are the pressures causing Blaze to be made to seem “sub-par”, is it due to the backers of each of the tech? Can it not be monetized? Being green behind the ears with it, it seems to me it would be the selling point for Enterprise Meteor.
I didn’t get any level of certainty from this message. Is MDG still working to improve Blaze or not? Are you simply maintaining its current state while working to improve Angular/React-Meteor until they are up to par with Blaze, then focusing exclusively on Angular/React once that happens?
I think the recent turmoil in this community comes from people not wanting to have their time wasted. I, for one, don’t want to invest enormous amounts of time in a serious project that is built off deprecated things, since it likely means those things will no longer be maintained. It’s a form of waste and I don’t have unlimited resources or bandwidth to spend flip flopping my projects around different technologies and playing with code that really has nothing to do with providing users with real world value so please just give a definite answer. As one member of the community has mentioned, it would be extremely helpful if MDG gave a list of intended or proposed developments for Meteor this year or for the next several months.
@gschmidt I’m actually happy to hear this news. Thanks MDG for keeping Blaze.
But please can you clarify this statement?
We’re going to continue improving support for other view layers (Angular and React) until they’re at parity with Blaze, including the Guide. In the longer term, we expect that most of the usage will gradually shift from Blaze to Angular and React. How long MDG maintains Blaze will depend on how much usage Blaze continues to get in the community, especially among our business customers.
Because this sounds for me like the exact opposite of this statement from you:
Speaking as MDG, we are going to continue making Blaze our main recommendation for new apps in Meteor, while also standing behind Angular and React for those that prefer them.
After calls from the Meteor Development Community for Tracker and Blaze to be treated as a first class citizens (meaning, for bugs to be fixed, enhancements to be made, and for both packages to be broken out into NPM), @gschmidt answered by twisting this on its head: He called for MDG to continue working to make React and Angular first class citizens (instead of Blaze) on par with Blaze, and when MDG thinks sufficient parity has been achieved they’re going to drop Tracker and Blaze from first class citizen status. See what he did there?
Listen, MDG has already made up their mind – they’re all in on React. That’s fine and it’s their call to make since, with the relatively limited number of Meteor users, and even fewer Meteor users that actually care about Blaze, no one in that pool has the inclination or bandwidth and know-how to make much fuss over it.
Anyone that has an issue with MDG’s choice has a decision to make, suck it up and make the switch to React or go to the few if any alternatives. MDG understand this, which one reason why they feel comfortable making drastic changes (such as this, but it won’t be limited to this I can assure you) at this point in time.
When is MDG going to stop flip flopping and stick to a specific path? This is what the Rails community keeps warning newbies about when venturing into Meteor. At least with Rails you know where you stand and have an idea of what is coming down the pipe.
Most applications don’t need React in the first place. Unless you’re building amazingly complex UI’s, on the scale of Facebook, you generally can ignore React. Seeing React popping up all over the place where it isn’t needed is just overkill. So many static sites are using React, just to say they are using React. Why? Epeen.
Stick to Blaze. It’s what helped sell your platform in the first place. Don’t let investors influence your decisions. Let the feedback of your users help forge your path. Focus MDG, focus.
that MDG will pick up the 
