There’s been a lot of discussion lately about what’s going on with Blaze, React, and the future of front-end rendering in Meteor.

To help make things clearer, here’s a quick primer in Q&A format. By the way, note that the opinions expressed here are mine, and not endorsed by MDG in any way.

So What’s The Big Deal?

Here’s a recap: ever since originally shipping in 2012, Meteor has always had its own front-end rendering library, with Blaze being the latest iteration.

Blaze’s job is basically to take your app’s raw data and logic, and mold it into something browsers can understand (namely, HTML code). As you can imagine, this is a pretty big job, and as such developing and maintaining Blaze has been a pretty serious drain on MDG’s resources.

Enter React. React fulfills more or less the same role as Blaze, is developed by Facebook, and has quickly established itself as a serious option for anybody building complex web apps.

The question in a nutshell: should Meteor keep its own homegrown framework to avoid disrupting its community, or embrace React to free up resources internally and reach a new class of developers?

How Are Blaze And React Different?

Besides the popularity and resources aspect, Blaze and React do differ in a few key areas.

For starters, React doesn’t have an actual templating syntax like Blaze’s Spacebars, but instead lets you mix JavaScript and HTML in the same file thanks to its JSX format.

This means there is no equivalent of Spacebars’ {{#if}} or {{#each}} control structures in React. Instead, you define a function that renders whatever would’ve been inside that {{#if}} or {{#each}} block, and call it within a JavaScript if or map.

In practice this makes for more complex code, but does have the advantage of forcing you to componentize your code (React is big on components).

Another key difference is that unlike Blaze, React enforces strict data control mechanisms. Without going into details, Blaze lets you pass data between your template pretty much however you like, while React is a lot more opinionated and tries to guide you into following best practices.

As Meteor user Brent Anderson points out:

Blaze lacks when it comes to handling local/internal state while React has this nailed down very, very well with props and composing nested component hierarchies, with data flowing from higher components to lower components

This translates into a much higher learning curve for React, but definite benefits down the road in terms of your codebase’s efficiency and maintainability.

Finally, Blaze is a lot more tightly integrated with Tracker, Meteor’s reactivity system. As Discover Meteor’s own Tom Coleman puts it:

The real challenge in porting an app from Blaze->React is not syntax changes, it’s a change in mental model in the way reactivity works – you have to pre-prepare all your reactive dependencies in .getMeteorData(), and then be non-reactive elsewhere in your component. This is a huge difference to Blaze where you can pepper your template with calls to reactive helpers.

So Which One Is Better?

If only there was a clear-cut answer to this question! As alluded to previously, both frameworks have their pros and cons:

Blaze is much easier to learn (you can learn it in a couple hours, vs a couple days for React), has a pretty useful and straightforward templating language, and is well-integrated with Meteor (reactivity works out of the box).

React on the other hand feels a lot more “grown-up”, since it enforces a lot of rules and guidelines that make it clearer what the “right” way to do any given task is. And while it’s not as tightly integrated with Meteor (yet), it does have a much larger overall ecosystem, and also supports a couple extra key features that Blaze doesn’t (such as server-side rendering).

So to sum things up, React is more powerful, but Blaze is easier to use and learn.

What’s The Big News?

Two months ago, Meteor 1.2 shipped with official support for both Angular and React.

Then last week, Geoff Schmidt laid out MDG’s plans for Blaze in a Meteor forums post:

So what we’re planning to do is to build templating on top of React, and to encourage Blaze users to upgrade to it (or, for those that prefer it, to plain React JSX).

In other words, Blaze is destined to become a thin layer in front of React that provides a templating language, better integration with Meteor’s reactivity, and makes React overall more approachable while keeping all of React’s other benefits.

This is a pretty awesome way to keep the best aspects of both frameworks. Yet all is not unicorn and rainbows in Meteorland.

Why Are Some People Unhappy?

While this is great news if you’re planning on jumping into the Meteor ecosystem in the near future, it does pose a few problems for people who are already heavily invested in Blaze.

Sadly, the Blaze to Blaze 2.0 transition will probably not just be a matter of typing meteor update. Any change this radical will probably require rewriting at least part of your template’s markup and logic.

This raises the question of what will become of all the Atmosphere projects built on top of Blaze, such as useraccounts or Blaze components among many, many others.

What Should I Do Right Now?

Knowing MDG’s slow meticulous approach to development, this new “Blaze 2.0” layer will probably not see the light of day before 6 months to one year. So what should you do until then?

If you can, use React. Mastering React has immediate benefits beyond the Meteor ecosystem, and React apps will not require any migrations whenever Blaze 2.0 comes out (since Blaze 2.0 will work on top of React).

As MDG’s Sashko commented:

I think a 100% foolproof way to go would be to start using React now. The “Blaze 2” thing is mostly for people who don’t want to deal with the details of React and its JSX syntax, but if it works for you then I’d say that’s the way to go.

But of course, there’s a whole lot of reasons why using React might not be practical. Maybe you have a legacy Blaze codebase, you don’t have time to learn React, or you just don’t like it. In this case, feel free to keep using Blaze.

After all, while the upgrade path to Blaze 2.0 won’t be completely transparent, I trust that it will still be quite manageable.

What Can I Do To Make Upgrading Easier Down The Road?

Assuming you’re sticking with Blaze for now, there’s a few things you can do right now to make your templates more “React-y”, and hopefully closer to whatever Blaze 2.0 will look like.

For example, you can take inspiration from React and start avoiding passing a “naked” data context. In other words, don’t do this:

<template name="myTemplate">
  <h3>{{title}}</h3>
</template>

But instead this:

<template name="myTemplate">
  <h3>{{post.title}}</h3>
</template>

Also try to avoid using any jQuery or DOM manipulation code in your template’s onRendered callback, since React doesn’t like you to manipulate the DOM directly.

And whenever you can, it’s always a good idea to take your logic out of your templates and into global helpers.

Check out Abhi Aiyer’s Blaze tips for more ideas on how to clean up your Blaze code.

What Are Some Alternatives?

If you want to go rogue and forge your own path, you don’t have to wait for MDG. You can use Spacebars with React right now thanks to the Blaze-React project.

I don’t know enough about Blaze-React to know if this is the direction MDG will eventually embrace, but there’s certainly been a lot of communication both ways thanks to James Gillmore’s abundant forum posts. So let’s hope everybody can work together towards a common goal.

What About Discover Meteor?

Finally, this brings us to our book. After lengthy discussions between me and Tom, I think we’ve reached a reasonable conclusion.

Discover Meteor’s mission has always been taking you through building an app from start to finish. So besides a few HTML/CSS/JavaScript basics, we don’t require any prior knowledge to get started.

We want to keep this philosophy, so if we used React we would have to explain that, too. The issue here is that React is complex enough to warrant entire books and courses just by itself. Trying to teach both Meteor and React in the same book would just be too much.

So for that reason alone, we’ll keep Blaze for the book. That being said, we’re thinking about ways to make the code patterns we use more “React-y”, following the principles put forward in the Meteor guide.

And if we do our job properly, this could potentially pave the way for a bonus section where we show you how to swap out Blaze for React.

Or who knows, maybe by then Blaze 2.0 will be here and will make this whole debate obsolete!