Interesting. Didn’t know that Babel could handle JSX.
Well, on a pragmatic level, if you’ve got spacebars seamlessly working on top of react, that seems to clear up a lot of the questions regarding refactor paths, legacy code, and code migrations. That could possibly be an ideal approach.
Blog post please with some examples 
It should speed up some actual testing with this by the community
My package is not surviving hot code pushes, but i might change ReactiveVar for ReactiveDict and then i can (?)
What i internally do is figuring out the template instance used and attach the ReactiveVar to it, so it can be set from any helper and event by simply using TemplateVar.set()/.get()
At least its the simplest way of having a template instance specific state IMHO: http://atmospherejs.com/frozeman/template-var
For templates that are used once you can make it survive hot code pushes automatically. If the template is used multiple times then you need to be supplied with a unique name for each template instance.
It would be cool if Blaze did that for us (template instance vars that survive hot code pushes) but after Sashko 's comment I wouldn’t wait for it.
After writing a lot of React Native code the past week… I’m starting to think that the best/fastest/productive way is to use Blaze for most/half of HTML templates and anything that can be a component would be handled by React.
This keeps blaze simple and fast to write and complex templating/logic is handled by React.
I haven’t tried this with Meteor yet but hopefully Blaze will add tighter support (if needed) to allow you to drop in a React component into a Blaze template with ease. It could be the best of both worlds 
Also agree. I’d like to see modules/lazy loading introduced before such a dramatic shift is made
I’ve been working with JSX and Spacebars, both, and I prefer Spacebars.
This statement will seem obvious, but I find embedding HTML inside JavaScript is a major violation of the separation of concerns principle…
Blaze is brilliant and I’m not against new ways of using it, but supporting Spacebars templates should have high priority until some new method has proven itself over time.
In regard to using React with Meteor – in my opinion, the Range API is what makes Meteor’s UI awesome, and changing to a Virtual DOM approach would be throwing the baby out with the bath water.
I wrote a package some time ago that let’s you do this. https://atmospherejs.com/dferber/react-create-blaze-template
Spacebars is Exactly what we need. Knockout offered semi-reactive vvm style templating using handlebars. It only makes sense that we would see a logical evolution. I personally MUCH prefer the idea of templates with LIMITED inline logic (Basic loops and conditionals allowed because I can’t imagine a single case where I haven’t taken advantage of those) and the actual definition of “WHAT” to display and how to react to user interactions being in a separate “helpers/events” file.
It works very well (much better than I would have expected) and with the template inclusion as a first class concept (instead of second class like handlebars had it) you move towards small componentized concepts.
I’ve developed in PHP with both inline php (god help me) and with “phtml” style. I’ve developed a bit in haml, I’ve done Java/JSTL (both front and back end), I’ve used knockout both with and without handlebars templates, and I’ve used spacebars. Of that entire list, Spacebars is my preference, by leaps and bounds.
Coming from the PHP camp. I spent over a decade working on my own CMS which strictly used Smarty templates. Adapting to Handlebars/Spacebars was trivial… aside from the lack of features and intuitive logic / native-contextual-variable-access (could be tricky that part).
I would like to see Spacebars strive for that, and indeed just forked it a little while ago with the intention of /possibly/ doing so myself. 
One thing is for sure, it’s nice to see your HTML structure while working on anything front-end related.
IMHO template, style and helpers are all belongs to presentation logic and separating them should be optional.
We will probably have components with Blaze 2 release. If MDG delivers a JSX transpiler along with Blaze 2 we can choose to write something like this:
var Comp = new Blaze.Component({
render: function() {
return (
<div className="layout">
<h2>{this.get("title")}</h2>
<div className="content">
<Blaze.Template template={this.get("content")} />
</div>
</div>
);
}
});
or like this:
var Comp = new Blaze.Component({
render: function() {
return Template.layout;
}
});
I think JSX syntax might give us more control over our components.
JSX is pretty neat, I’d still like to see a pure-js option.
var Comp = new Blaze.Component({
render: function() {
return (
div({class:'layout'},
[
h2({}, function () { return this.get('title') }),
div({class:'content'}, function () {
return new OtherComp({template: this.get('content')})
})
]
)
)
}
});
var PostsList = new Blaze.Component({
// helper (could be written in a different namespace)
posts: function () {
return Posts.find({isPublished: true})
},
render: function() {
return (
div({class:'posts'},
// get could handle the reactivity / convert to an array
_.map(this.get('posts'), function (post) {
return div({class:'content'}, function () {
return new PostView({postId: post._id})
})
})
)
)
}
});
Just a thought, I mean, yes, it’s more verbose, yes, it’s not html, but I think it provides a bunch of power…
It looks nice in coffee though:
PostsList = new Blaze.Component(
posts: ->
Posts.find isPublished: true
render: ->
div { class: 'posts' }, _.map(@get('posts'), (post) ->
div { class: 'content' }, ->
new PostView(postId: post._id)
)
)Could/would you kindly provide good/detail examples of what a React and Meteor/Blaze template/component would look like?
That’s the first appealing thing I’ve heard about React over Blaze that resinates with me.
Will you please expand on this with more explanation and examples. I’m trying to come around to React, but I’m having trouble getting the ‘ah-ha’ moment.
React is a mix of a few different technologies, is truly ‘pure javascript’, and gets performance boosts by ditching the HTML and CSS subsystems.
@awatson1978 personally I want to place my bet with famous.org and the wonderful job @gadicc is doing with famous-views. How do you compare react to to the new famous? They both provide virtual-DOM and famous-views works with blaze and not against it. Plus we have the wonderful mixed mode now. I don’t think famous is dead, I think it just got better. Thoughts?
Here’s a snippet from @timbrandin 's package that is under development. I think the idea is to have the same API as Blaze but use React under the hood. You could even use community React components.
https://atmospherejs.com/timbrandin/jsx-templating
<template name="Page">
<div class="page">
Hello world
</div>
</template>
would compile into:
Page = React.createClass({
displayName: "Page",
render: function() {
return <div className="page">Hello world</div>;
}
});
I personally think deprecating Blaze is silly, even as much as I like React. Personally i’m glad the they’re integrating other view layers such as Angular and React because it makes everything more decoupled.
If anything a Blaze 2.0 that desugars into JSX would be more ideal than deprecating. I think there’s a lot to gain from a library that spends so much energy on just the view layer.
@timfam - Yeah, I’m pretty convinced that we’re going to be able to get Famous, React, and Blaze all working together nicely.
Famous Mixed Mode is definitely what people were hoping for with the initial Famo.us release. Yeah, it came a year later; but if the periodic demo is any judge, it seems to be delivering on what it was promising.
Our approach going forward is something along these lines:
Personally, I see no reason to deprecate spacebars. But I do see lots of reasons to have refactor paths to/from spacebars, so folks can work with different levels of encapsulation/abstraction. I think it’s a good sign that there’s both an attempt to render React to Blaze, as well as an attempt to render Blaze to React.
I completely agree with you