Tell me: What's it like to use React with Meteor?


Hi Meteor Forums!

Sashko here from MDG.

We’ve all heard a lot about React. I’m trying to learn more about what it’s like to use React with Meteor. Have you built an app with Meteor and React? Help me find out more by telling me about:

  1. What patterns you have figured out?
  2. What problems come up?
  3. Is there anything makes using React feel not “integrated”?
  4. What are the pros and cons of React vs. Blaze or Angular, when used with Meteor?

I’m also going to talk directly to some of the people I know are working with it - devshop speakers, etc - and I’m going to try building some apps with React myself to find out more firsthand.

Thanks ahead of time for the info!

CC @avital @dgreensp


Did you see the TodoMVC in Meteor React demo? It provides a very nice compare/contrast between Blaze and React.


There’s really a lot to like about React, but the thing that doesn’t feel integrated to me is the render() function and all that html within the javascript.


What are the pros and cons of React vs. Blaze or Angular, when used with Meteor?
Angular don’t fit well for quick development and have curve learning.

React has finer controls on rendering and processing data.

Blaze is less error prone and stable, less barrier than Reactjs.


I luvs the HTML in the ES6, and now they’re completely throwing caution to the wind and putting CSS inline too. I think it’s much better to have full encapsulation in a single file if you’re building with components. I can’t stand flipping views constantly for really no benefit and the cascading part of CSS is much of the problem both in brittleness & performance. Furthermore, inlining cuts down code complexity by getting rid of the clunky glue code, which is a language-within-a-pair-o-languages that no one should need to learn.

Best Practices Found Harmful.


By far the best advantage of react is IMO that not only you have clean view components, but even more that you can define them expressive in a single file (JSX or CJSX syntax). It really slows me down when I constantly have to flip between files (html, css, js (or preprocessor pendants)). But it needed a while doing React to even realize this crucial time/concentration wasting. And I already use multipane editors like sublime/VSCode on a fairly large iMac 5k retina screen to ease the pain… .

Having said that, iterating over a bunch of stuff in React is quite cumbersome compared to Blaze’ {{#each}}. In Terms of sheer simplicity and accessability and learning curves, Blaze rocks. If only inline-html and inline-styles were possible in an easy way like react does it.


React with meteor was painful for me. It’s been so bad I’ve abandoned meteor 3 months into a startup project in favor react/node front end a rails api backend. I’m currently rebuilding the whole thing while already having a client wanting to start adding his users to it… That’s how bad meteor and react was for me.

At first it was ok, after some minor hiccups it was working. Then I ran into a lot of trouble trying to use react community packages. A vast majority of the react community assumes we are using webpack/browserify to bundle our project. I haven’t found a good solution to this in Meteor. So I can’t use non-meteor community packages like react drag-n-drop, etc. Ok, that sucks but I could live with that.

But it gets much deeper than that the further I went along. Eventually I found they are actually at odds with each other conceptually.

We have react which promotes self contained isolated immutable little functions that represent the UI at any given time. It is optimized for ease of understanding what the code is doing when you have to add a feature 2 months in the future. A component only knows about itself and what props it was handed. That’s it, that is all there really is to react. A parent component gets some data and populates child components passing in data that they need. Those children have no knowledge of the parent or anything else in the system. I love this. Using a build tool like webpack further enforces this, I can only use the files I explicitly require.

Blaze is the opposite, purposely optimized for speed at development time. Every template can call any other template instance and do stuff to it. Working with an external API like stripe is just ugly. Session variables (ReactiveVar is better but still has issues) to check if a user interaction is active… Helpers in separate files that create really tight coupling between logic and the display of UI. So much of it is in direct conflict with react at the core, and I personally like the react concepts more. I really don’t want to start flames here, just stating my personal opinion from building out a SaaS project first in rails, then in meteor, then in react. If you love blaze and feel the need to correct me, please move along.

But ok, let’s try abandoning blaze completely and use just 1 template with react. First, we’ll need to replace the routes, there’s react-router. Awesome router concept btw, nested layouts of visual components is brilliant (thanks ember). But how do you use react-router? var Router = require('react-router'); When I try to include it all the files and dependences it relies on break. Bummer.

Looks like there might be some progress on getting this to work, but not there yet. Well, ok, we can use the meteor router and just render react components inside empty blaze templates. Works decently, and there’s some pretty cool features like startMeteorSubscriptions to reactively render collections, awesome.

Now getting pretty deep into nested child templates that passing along data is getting out of hand, and if I change one I have to change the whole tree of child components. So what’s this Flux stuff about? Actions, dispatcher, and stores make sure I can only have one source of logic (stores) and one source of manipulating the state of the app (actions). That sounds like it could solve some of my complexity problems. How do I use it? var Dispatcher = require('flux').Dispatcher; Uhhhhgggg…

So, that’s what it was like for me to use React with Meteor. Believe me, I would LOOOOVE to have this figured out. I really enjoyed Meteor, but have a distaste for Blaze (any template engine really, like handlebars, rails mvc, etc) when compared to isolated components. I would be so happy to use Meteor for my server api and webpack with react for my frontend, all on one deployed server.

I could imagine the Meteor server files acting like Flux stores and the client folder holding the components and actions would be a brilliant way to work. Helps enforce security since I can never manipualte state from the front end, I can only create actions and the server updates the collections and creates new actions to dispatch the results, and in some cases wouldn’t even need to, the collection would just reactively update in the view, react diffing efficiently blowing away the old content with the new data.

The closest thing I could find was Asteroid, but in my initial tests I was unable to get it to work on two separate deployed servers, likely due to some CORS stuff. I didn’t investigate too far since I realized that if I am running two servers and separating the client and server, I might as well just use a rails API that I am familiar with, or even Firebase would do almost everything a separated Meteor api could.


Hey this is great - just what we were looking to learn about. Would you have time to get on a phone call in the next few days? PM me or email at!


From my point of view and personal opinion:
1- integrating with react is a strategic movement for meteor with huge community support.
2- integration means using blaze & react side by side in one project, this is the power.
3- blaze itself should evolve for better performance and react like flexibilities.
4- meteor as a back end solution is great for react community and will empower and mix 2 big communities of emerging development methods.
5- I think MDG should clarify their opinion on future of this idea.

Thanks, just some personal …


Thanks, that is what i am looking for for weeks. The following quote seems better than others.


Hi Sashko:

I have started this week a series of posts about using Meteor with React. You can read the first post here:

It aims for beginners so I am starting with very basic stuff and I will explain more advanced concepts in following posts.

Any feedback is more than welcome.



Combining React with Meteor has become almost trivial with the use of Eli Doran’s wonderful cosmos:browserify package. People considering working with React and Meteor might want to take a look at Meteor, React and Material UI the easy way by Luigi Maselli, which explains how to set things up. The approach outlined in that article works for many React packages including react-router.


Great post… starting on this as well. The main downside (for me) is the use of coffeescript so I have to translate to get the pure js version of it.


@anonyfox, @SkinnyGeek1010, @shock, @tehfailsafe - how about helping @timbrandin to get the Sideburns cooked?
Do you guys think having such layer with Meteor-ish-React style would be a way to go?



I am lazy, so I dont work on anything bigger than I need or may need in future.

And this Sideburns looks like nice project for people to migrate, but from my point of view it does not teach you the React+Flux way. In Meteor we have actions coming from all directions and without correct scope shadowing this seems to me as renaming Blaze to something what seems like React, use react on backend, but have same issues as Blaze.

For example I wanted React + SSR + material design, so I checked how these work atm and most used material-ui package needed some update to work at least in development environment, but it kinda works and I could play with it. This was the result:

Now I would like to try and incorporate some flux to my flow and will check SkinnyGeek1010’s examples.
Also atm I have no idea how I would do kinda template level subscriptions and re-subscriptions when I update input and hit search button. And monitor for subscription ready - these are basic build stones for me.
And I am just starting looking into React. So no expertise to expect from me :smiley:


I’m working on a mobile app.
I’ve already done cordova apps with react.
I use the react package and don’t use any flavor of flux at the moment.

My general feedback :

  • I don’t feel like I need Flux. The reactive model of Meteor and reactive-dict/var/session are more than enough for my use case. Maybe I’ll have to find a way to structure shared data model and events, but I guess it will stay in Meteor’s scope.
  • I don’t need SSR, but I keep an eye on Arunoda’s work.
  • No serious issue so far.

I stick with React at the moment. I like it’s simplicity and JSX. I’ve been annoyed by Flux implementations, too much cruft, some overcomplicated implementations of simple concepts.

The pub/sub is backed in Meteor and minimongo is like a supercharged Flux store. All in all I still have less lines of code than an equivalent app with a different backend and I keep my beloved “get it for free” latency compensation.

The ReactMeteorData mixin is convenient, easy and powerful. After about 2 years of using Meteor I’m still impressed by the extensibility and productivity provided by the platform.


I think it’s good open Meteor to consolidated front-end library such as React and Angular. But I prefer to see a Blaze update in the future with a series of template implementations and more reactive Spacebar helper to facilitate the developer works instead to write a tons of code for any template.
About React, I don’t like to write HTML code inside JavaScript element.


I wish I had the time but my freelance jobs are consuming my time. I think sideburns is great but I don’t like working that way (that’s the reason I got away from Blaze).

Most of my time is consumed with Meteor + flux because it’s helping me eliminate the ‘whack a mole’ strategy of maintaining a large Blaze codebase (global reactive data re-rendering view(s) in no obvious way). Other Meteor devs I talk to have to same issue at scale (as in many devs, many templates).

To me it seems like a great project but IMHO there’s more to learn in using sideburns than just learning vanilla React.

You may find Alt interesting. It’s minimal and still useful. For example a simple db backed counter just needs the following:

// watch a Meteor collection for changes
trackCollection(Counter, AppActions.counterChanged);

var AppActions = alt.generateActions(

class AppStore {
  constructor() {
    this.bindActions(AppActions, FooActions);
    this.state = {
      counter: Counters.findOne()

  onCounterChanged() { // refresh store with minimongo data
    this.setState({counter: Counters.findOne() });

  onIncrementCounter() {
    var newCount = this.state.counter.count + 1;
    var id = this.state.counter._id;
    Counters.update(id, {$inc: {count: newCount} });

var CounterView = React.createClass({
  mixins: [ StoreStateMixin(AppStore) ],

  getStoreState() { // or you could manullay listen w/o mixin
    return {
       counter: AppStore.getState().counter

  render() {
    return (<div>Current Count: {this.state.counter.count}</div>);