[avital]

Hi, I work on Blaze.

React and Blaze both compile templates or components into an intermediate representation for their HTML structure (React's JSDOM; Blaze's HTMLJS). A lot of the difference in how they decide what DOM changes are necessary.

React re-renders components when data changes and diffs the resulting JSDOM. The diff algorithm is fast and has simple hooks to make it faster by letting you compare state and component properties.

Blaze doesn't diff the resulting DOM structure. Instead, Blaze diffs the data the components depend on. That data comes from reactive functions built on top of Deps, our dependency tracking system. When the component first renders, dependencies are tracked between data sources and rendered DOM elements (dependencies are automatically cleaned up when the component is taken off the page). Therefore when data changes, Blaze can directly update the relevant elements.

There is some overhead in Deps, our dependency tracking system, but Deps has been intentionally designed for supporting this efficiently (eg batching updates in a "flush" stage).

As for performance, our benchmarks have generally found that React outperforms Blaze when many elements change and Blaze outperforms React when few elements change (which is more common for typical operations on many web apps). We also have plans to improve performance on initial rendering.

There are some other difference worth noting: While a later version of Blaze will support easy APIs for re-useable components, React already has one. And the React component model is well-thought out, complete and in production use whereas the Blaze component model at the moment is only the implementation behind templates.

Happy to hear any other perspectives.

[rtfeldman]

Not to detract from the positivity of sweet new tech, but it's worth noting that "React outperforms Blaze when many elements change and Blaze outperforms React when few elements change" is the same as "React outperforms Blaze in cases where the user is capable of noticing a performance difference", which reduces to "React outperforms Blaze."

Nevertheless, seriously appreciate the detailed and informative response. :)

[myhf]

I'll have to see how each one handles a big grid of rotating colored circles with numbers on them in order to make an informed decision.

[imslavko]

Does it mean that, theoretically, Blaze will still outperform React on a long series of small quick updates conducted by a lot of disconnected events?

[ZeroGravitas]

That might be true, but it doesn't automatically follow. Java often gets dinged for startup time that it might make up for on longer runs and browser vendors seem to be sniping that their rivals are focussing on long term benchmarks at the expense of realistic workloads.

[vjeux]

If you use `shouldComponentUpdate`, then React outperforms Blaze on the circle benchmark for both single and large number of updates. See Andrey Popp JSFiddles: https://groups.google.com/forum/#!topic/meteor-core/-px_AGhj...

React by default is fairly fast but what makes it stand out is that it gives the tools to make the bottlenecks faster without having to drop the nice abstraction.

[masklinn]

Popp's fiddles don't use shouldComponentUpdate, as far as I can tell. They replace using props (application state) by components-local state and an animation prop. I'm not entirely certain that his semantics map to the original ones (in terms of expectations).

[vjeux]

My bad :x JSFiddle is unusable on mobile and I assumed it was using shouldComponentUpdate. Anyway, the conclusion still holds, you can refactor your code to be performant while keeping in the React paradigm.

You have a lot less control over the performance of your app with data binding.

[masklinn]

> Blaze doesn't diff the resulting DOM structure. Instead, Blaze diffs the data the components depend on. […] Therefore when data changes, Blaze can directly update the relevant elements.

FWIW this is available to React as an optimisation if desired/necessary: by default React just renders the whole component tree on data changes[0] and diffs the result tree before updating the DOM — which is simple and usually performs well — but components can implement shouldComponentUpdate[1] to skip re-rendering if unnecessary[2].

[0] a React component could depend on non-react data, React is conservative and does not assume components depend only on data it can track

[1] http://facebook.github.io/react/docs/component-specs.html#up...

[2] and React provides ReactComponentWithPureRenderMixin[3] which can be mixed into any "pure" component whose output depends solely on application and component state, to get a free shouldComponentUpdate

[3] well "provides" may be excessive, it's in the repository but seems to be neither in the react distribution nor in the react-with-addons distribution. YMMV.

[TylerE]

I have to say I'm pretty excited, since it now looks like there is a non-hacky way to use jade templates, which as far as I'm concerned are a big win. Any more details to shed on that aspect?