At first glance, this seems much better in terms of programmer productivity, given that it uses logicless templates rather than embedding HTML inside JS code. But I'd be curious if it's less performant.
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.
Nevertheless, seriously appreciate the detailed and informative response. :)
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.
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.
Here is one of the React core developers (Pete Hunt) on React integration with Meteor: http://www.youtube.com/watch?v=qqVbr_LaCIo (note this is before Blaze)
Regarding performance: https://groups.google.com/forum/#!topic/meteor-core/-px_AGhj...
React will probably be easier to reason about down the line (despite the initial learning curve), while Blaze will "just work".
[0] https://github.com/tildeio/htmlbars/blob/master/ARCHITECTURE...
HTMLBars is an excellent project and indeed does share many design principles with Blaze. They also differ in a few ways. For example, HTMLBars plans to never support full inline expressions in templates, whereas that is an explicit future goal for Blaze. So even though parts of HTMLBars could have been used in Blaze, it wouldn't give us the flexibility needed to take Blaze in the direction we think is best for our users.
[edit: Also, Blaze is shipped. :)]
However, the tricky case they've run into:
<template name="hello">
{{#if bold}}
<b>Hello {{name}}!</b>
{{else}}
Hello {{name}}!
{{/if}}
</template>
<template name="hello">
<b tal:omit-tag="not:bold">Hello {{name}}!</b>
</template>Without this feature, it's hard (or harder than it should be) to create reusable user interface code.
I'm sold on JS, as to me PHP is very ugly and incomprehensible. My stack currently looks like this:
Node -> Express+Passport+Mongoose -> Bootstrap + Angular/Polymer + D3
I've only begun my project three weeks ago, but I would have hoped to have a prototype by now. Admittedly, I'm not working on this 40hrs a week, but still. I find it very hard to understand how everything fits together.
And then news like this appear, once or twice a week, which make me spend some hours reading on this or that new framework and how better it performs.
</rant>
[1] I did some flash, html and js about 6-7 years ago. Also learned enough php to be disgusted by it.
I've tried something similar, that is Rails + Ember.js, and I find using Meteor.js easier.
The reason I didn't go with Meteor at first was that I didn't really understand how everything fits together. I needed to build a stack block by block. But that was three weeks ago, I will definitely read more about Meteor and maybe give it a try.
One thing's sure, I have to make up my mind sometime soon or else I'll never have a prototype!
I am a new developer. I've used meteor for a couple toy projects, and found it really easy to get started. past the basics however, I found it really hard to get answers. I'm currently trying to write a simple backbone + node app to get my head around all the things meteor does automagically.
Are there any plans for learning resources coming from the meteor team?
Recently rebuilt a client app in Meteor, ran into a few hurdles that I think are just part of the learning curve.
A few times I have come to the github wiki page & found some helpful tips: https://github.com/meteor/meteor/wiki
http://www.meteorpedia.com/ is in pretty active development, lots of links and the guys who run it are active on the Google Group also.
The videos on Evented Mind are fantastic to learn from as well - https://www.eventedmind.com (recently introduced a subscription model, though, some of the videos are still free to play).
http://pluralsight.com/courses/meteorjs-fundamentals-single-...
I will try it out this weekend.
You have a lot less control over the performance of your app with data binding.