Based on Geoff Schmidt’s talk the other night, it seems Meteor might one day soon be very pro-opinionated on towards entire Facebook (FB) stack (with the addition of DDP):
It doesn’t make sense to adopt React as the official view layer, but not all the underlying tech that FB builds around it, the tech that synergies and complements it.
Yes MDG will include support for Angular and whatever else that comes along. But they are officiallyopinionated on React. It seems once they have pugged in GraphQL, why would they not too be officiallyopinionated on the tech from FB that complements it.
Also, its reasonable to conclude we should also consider ReactRouter over FlowRouter based on the same premise.
What about Flux? Will we get something like MiniMongo with GraphQL (MiniGraphQL perhaps)?
Reading the tea-leaves, it seems time to start embracing the FB stack.
I’d like to start a conversation about the migration of Meteor to the FB stack: maybe – ramifications, great resources, beginners guides, best practices, pitfalls, and maybe even how-to’s for Blaze 1 to React.
Hopefully this thread will serve as a guide and reference on the migration.
I’d like to advocating for the Meteor community to get help with the transition in the form of a deep dive video on Rewriting Blaze 1 into React components similar (but more in-depth) to the one @fvgposted? A how-to that covers converting from the bottom up – not the top down – component by component (I’m talking only a portion of a Blaze 1 template small).
This is a really great thread! I wonder what people think of all of these new technologies that are coming out. One thing that’s interesting is that people are naming the whole thing together “the FB stack” - if you look at the picture in the first post (Angular, React, Webpack, ES7, GraphQL, NPM), I don’t think that’s a fair description.
There’s been a ton of discussion around the issue, but we’re on board with the fact that React is basically what we would have wanted to build as the next version of Meteor’s frontend, with small cosmetic differences. Angular is great as well, and I don’t see Angular and React merging anytime soon, so it makes a lot of sense to support both equally, while nudging new developers towards React as the default because it seems to be simpler to understand conceptually.
Webpack has become entangled with React, but is a completely independent project. There are tons of alternatives to webpack that different people use with React, for example Browserify. The thing that’s exciting about Webpack isn’t that it works with React (that’s easy to do), it’s the code splitting and hot module reload functionality (that’s hard to do).
ES7 is literally a JavaScript standard, so I think it makes sense for everyone to adopt it.
GraphQL is what you would end up with if you asked yourself “I need a query language that is completely data source agnostic and supports basic joins”. In some sense, you could desugar GraphQL right now into a publish-composite publication and Minimongo queries. I think here it’s a similar story to React - while Facebook is the one that designed this language, it’s similar to what you get if you think about the problem hard enough. I don’t know that Relay and the options for GQL servers out there are that great, though, and that’s one place there’s a big opportunity to improve on existing stuff.
NPM in my mind is almost a de-facto part of the JavaScript language. It would be crazy to write any serious complex JS code without that repository of libraries, which is now one of the biggest package systems in the world for any language. That’s why Meteor 1.3 is working on seamless support for NPM.
Like I said in my Guide talk, I think you should be able to use any router you want to, so I hope that Meteor never does anything to make it hard to use React Router if that’s what you like. However it feels like React Router is the odd one out when you look at the React data story - it doesn’t follow a flux-type architecture, and it’s not concerned about splitting apart your data and your components. We like FlowRouter a lot right now because you can treat the URL as just another data source rather than having it be the backbone of your whole app.
Like I said above, it should be easy to use as much or as little of Facebook-produced technology in your app as you want. But we’re trying to take a principled approach where we evaluate each technology incrementally on its merits (modularity, maintenance, popularity, ease of use, technical capabilities, etc) rather than adopt a neighboring ecosystem wholesale.
I’m going to start a parallel thread about Flux and Meteor, one sec.
I would vote for a way how to replace minimongo with whatever u want.
After short look into source code, mongo driver itself is using LocalCollection methods to sync over wire. If we can define our own LocalCollection with added/removed/changed methods and feed for example Redux store directly without any minimongo, it could be quite performant and native way for React developers. As an example.
Just let us use our own frontend storage driver, similar as Blaze was made replacable.
I bet it’s intentionally not present. But as a general rule I think it’s very hard to assign meaning to absolute numbers for this kind of stuff; often only the relative magnitude is reliable.
I believe he said it was calls to meteor update as a proxy for installs. Still… just seems odd to omit the range when trumpeting adoption. I’m sure it’s not 5-6!
