Not so long ago Meteor Development Group announced that they would be ending ongoing efforts with their templating package (Blaze and Spacebars) and would be pursuing a potential bridge to help people get from Blaze to React using a new front-end rendering option. They’ve now tentatively reversed that decision, and it sounds like Blaze should stick around. Before we get into the why of Meteor needing React, let’s get into the how we got here, and then we can finish up with a little bit on how this all plays into the recent ‘Javascript Fatigue’…

Come on, how cute is that?

Lack of community acceptance

Meteor had an experiment where it tried to spin Blaze off into a standalone front-end library that people could use. The issue with spinning it off is that they didn’t have a big enough team to focus and compete with other offerings from Google and Facebook. I would say growing a project like this is a two-way street, and no one seemed interested, but as an open source developer, it becomes your job to educate people. Look at this forum that is a graveyard of unanswered questions:https://groups.google.com/forum/#!forum/blazejs. You get the feeling from looking at that google group that they weren’t super serious about getting behind standalone Blaze in the first place. But hindsight is 20/20, right?

The interesting thing that started to happen when MDG announced they would be moving away from Blaze is that I begun to see a measurable shift in people switching to React and investing the time to learn it. In the SpaceDojo slack chat, the React Channel is the second biggest and second most active behind our main chat room. People are investing time in revamping their existing project(s) too.

The failed SQL experiments

Meteor is a great framework for building applications, but if you are building anything more than a line of business application, then you may have some scaling concerns. A lot of people look for SQL as the potential great hope for scaling your app to more users. Meteor and Mongo do a good job of helping you scale up to a certain userbase size, and optimizations of your Mongo usage can certainly help extend that. But time will come when you need to start evaluating other options like SQL. The initial idea of having DDP as a protocol you could implement for other data sources — likely where you need to scale at this time in your growth stage. The problem is that Minimongo is tied pretty directly into how the Meteor client works, especially with packages like User Accounts. They could fix this up and make it easier, but spending time on creating Minipostgres for every other database option seems terrible in the long run.

It is clear that Meteor isn’t fully committed to this path, the current work looks like it is on hold:https://github.com/meteor/postgres-packages, the last commit being four months ago. It was always stated as an experiment that Slava wanted to try with his last two weeks at MDG.

Instead, it makes way more sense to embrace GraphQL and the ecosystem that is popping up around it. GraphQL has captured the attention of databases like RethinkDB, and they have GraphQL support built right into the database. I think MDG is in a unique spot to show up and contribute to building out the real-time options available in Relay, which Facebook is looking into right now: https://github.com/facebook/relay/issues/541#issuecomment-166303735.

The react community is just bigger

The very nature of a full-stack framework means that it is a HUGE commitment to start building your app with it. React is on the flip side of that ideal, you can just implement React and create your backend with any system. That means we have people using things like Rails, Django, or Node.js to build out their React apps. The overall community is, at least, 3x the size of the current Meteor community based on my (highly scientific) estimation techniques. The community size is because people can just dive in and bolt React on to any development project.

Facebook has done an excellent job of letting the community involvement drive React. Let’s take a simple metric to compare React and Meteor contributions (I tossed in Rails as a control):

React has 6k commits and 600 contributors (10 commits per contributor on average)

Meteor has 15k commits and with 258 contributors (58 commits per contributor on average)

Rails has 55k commits and 3k contributors (18 commits per contributor on average)

My hope is Meteor can find a way to follow Facebook’s example and embrace the community more. Trust this community of users to help build out this great framework.

** Sidenote **

As I was wrapping this post up, Sacha started posting his thoughts too, and they seem to echo a lot of what I’ve been feeling lately too. Building components with both the client and server working in tandem has been a great asset in Meteor so far.

Embracing the Facebook stack

I was talking to a friend recently and compared the current state of Meteor to that of Apple deciding to announce new MacBook Pros, five months in advance. That would most certainly start to tank sales on their current product as people would rather wait. We are in that strange state where things like Testing, build tools, and even data layer will likely be changing in the next year. While I think these are smart moves, it starts to make people apprehensive about where the stack is going and what will happen to their upfront investment into Meteor as their stack. Here is why I think embracing more of the Facebook stack makes sense for MDG in the long run:

GraphQL will be around for a long time and adopted by a large community (like rethinkDB)

Developing something like the tooling around React will take time and be expensive, why duplicate that effort?

ReactNative is super interesting and buying into React should give us an easy path to ReactNative.

Final thoughts on a javascript stack

Many of us longingly look at other tech stacks and think “Why can’t I easily do that with my stack?”. It is clear to me that the grass may look greener, but that doesn’t mean it is. I don’t look at any of these topics of picking a library or framework as a holy war to be waged against another community (despite doing that myself a few years back), but instead, choices that we get to make, and hopefully, we pick something that fits the business needs. At the end of the day, we are all developers trying to build software that helps facilitate businesses doing some profitable commerce. 25 years from now, none of us will care about Rails, Django, or Meteor just as most of us don’t think about Fortran or Assembly now.