Adopting the React Stack in the Meteor framework


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):

Screenshot from this presentation.

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 officially opinionated on React. It seems once they have pugged in GraphQL, why would they not too be officially opinionated on the tech from FB that complements it.

Screenshot from this presentation.

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.


Is the Geoff Schmidt’s speech available to see somewhere, please ?


I’d like to read the text as well.



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 @fvg posted? 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 the video describing the technique:


According to @mbrookes MeteorChef has a pretty comprehensive write-up of converting the MeteorChef base app to React:


Again, according to @mbrookes Until Blaze 2 arrives, if you only want to convert part of a template, this may help:

There’s also this project, but it’s WIP, so not complete yet:


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.

  1. 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.
  2. 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).
  3. ES7 is literally a JavaScript standard, so I think it makes sense for everyone to adopt it.
  4. 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.
  5. 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.


MDG will have to solve the package system in client first. For me it’s far behind from what we have today on npm’s ecosystem.


Meteor 1.3 will have this: you can type npm install in your app, and then import that module on the client.


Here’s the promised thread about Flux and Relay:


@sashko could we by chance get the Y axis range for this graph Geoff Schmidt used in his presentation? Strange omission.


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!


Okay got it. Here’s the reason why Y-Axis matters. If y-axis starts from the ‘zero’ this is great. (I assume, it is).

Otherwise, it’s a common marketing trick to start y-axis from somewhere at the end to show a fake growth. Apple did it so many times :smile:


Good point yet if Meteor started on day one far up on the y-axis, that would be strange!! So it probably is from zero.


What I heard: y-axis is number of unique IP addresses to the Meteor update server.


I think it is also interesting to make it clear if the scale is linear or exponential (looks like linear, which is fine too).