The React+Meteor Package Ecosystem

Last night at the Paris Meteor meetup we had a great roundtable debate about the future of Meteor.

Most of us agreed that Meteor’s future involved React, and I think most people would be ready (or maybe resigned…) to make the switch, if it weren’t for one thing. When you switch from Blaze to React, you lose Autoform, User Accounts, Tabular, and all the other awesome Blaze packages that make building Meteor apps so easy.

Sure, there’s data table packages for React, but they only address one half of the equation. The huge advantage of something like Tabular is that it also takes care of publishing, filtering, and paginating your data for your server-side. And this is only possible with Meteor (and is a big argument why Meteor can potentially become the best React back-end around).

@gschmidt said it himself:

The biggest strength of Blaze is the ecosystem around it - all of the amazing packages and components that our community members have written and generously shared on Atmosphere.

So my question is: how can we replicate this strength, but with React? Are there React alternatives to the most popular Blaze packages? If not, what are people currently using?

My personal dream solution would be for MDG to sponsor an effort to create these packages. I think this would be both very useful in getting the Meteor community to switch from Blaze to React, and also very attractive for the part of the React community that’s not using Meteor yet.


IMO Meteor should build a new front-end system around React, and forget supporting other stuff. This would get the community aligned and provide one path forward for publishing packages, tutorials, etc.

Supporting other front-end frameworks seems like a marketing move, and it does not seem to be very effective (judging from download counts). IMO the focus should be on making Meteor a strong, integrated, solution, and not on supporting other framework.

As Donald Trump would say, “Let’s Make Meteor Great Again.”


Really, you saying this :smiley:
I hope you liked Blaze and wanted it from MDG.
When did you switch and what made you?

P.S. I was like you and did the shift long ago :smile:


I love Blaze, and I am not saying that this new front-end solution couldn’t have Blaze-like syntax :smiley: This comes from the place of desiring a truly integrated front-end solution that will be improved/supported.

Right now, Blaze is the truly integrated solution but does not seem like it will be improved. React/Angular are not truly integrated solutions, but it looks like they will continue to be improved.


Haven’t a similar idea generated 100000000 angry voices of protest not a long time ago?


I guess it’s 100000000 + 1 now

1 Like

I’m a fan of minimal APIs. One thing we’ve done at workpop is keep our code doing exactly what it meant to do. I feel a lot of Meteor packages have core solutions with tons of added bloat,maybe due to a feature request etc.

My opinion is your packages should handle a few set of things and that’s it. I’m okay with embracing the Npm community and building generic hooks into my publications, methods, etc. especially if you’re integrating with some flux framework, a lot of the pagination, sorts, filters can be saved client side the react way and fed into a publication.

You can still use Blaze templates in React as a refactor path. There are a number of packages that do the same thing, but I think that one is the best IMHO because it makes sure your blaze template updates when the props you pass in change.

There are React counterparts to those Blaze packages, but probably not User Accounts though. You can find React goodies here: (the new site)

It’s more than a marketing move. It’s about ubiquity and building a sustainable open source company that flourishes. That means agnosticism with seamless integration and support for the most popular frameworks - same applies for the data layer. The more people and organizations that build or rebuild their next app in Meteor, the better off we’ll all be. React support is crucial now, but isn’t the end all.

Really excited to see important Meteor frontend packages move to a model which is view-layer agnostic. I think useraccounts is almost there - there are just a few places where it has Blaze stuff hardcoded in the helper functions in useraccounts:core. And for form packages, it would be great to have something that does form generation and input parsing and validation based on SimpleSchema, like Autoform. If anyone wants feedback on designs for these kinds of packages, feel free to ping me!


"I will build a great wall — and nobody builds walls better than me, believe me —and I’ll build them very inexpensively. I will build a great, great wall on our southern border, and I will make NPM pay for that wall. Mark my words.”