hehe 
In my mind, components differ from templates by embedding markup in JS, compared to embedding JS into markup.
JSX vs Handlebars, I guess…
Do you disagree, and if so: plz tell me more 
So if Blaze had something like:
Template.example.render(
<h1>Hello</h1>
)
Would it then be a “component”?
1 Like
Note that Blaze does have this - it’s called HTMLJS and is used under the hood when compiling blaze templates. But we didn’t bother documenting it well since we assumed people would rather write HTML.
3 Likes
nope
I think JSX is a great part of what makes React awesome (and better than Blaze templates for me). I’m sorry if my opinion is provoking you, and I hope you will try to change my mind if you disagree.
I should probably put this into other words: I think React components are better than Blaze templates. And don’t get me wrong, I enjoy working with Blaze, There’s probably just been A LOT more hours poured into React (as I know MDG has a lot on their plate already).
1 Like
I’m trying to get to the reason why you think with React you have “components” and with Blaze you have “templates”. You said “components differ from templates by embedding markup in JS”. So why wouldn’t you consider Blaze to consist of components if it allowed you to embed markup in JS?
I think of components as tightly knit view-elements that allow me to mix my javascript with my html in a very direct way. This is contrasted in my way of thinking about templates, where I feel there’s some fragmentation, having to split things up and map them together.
The fragmentation between how I handle lifecycle/events/helpers with templates has been an issue for me to deal with as my applications grow, and I’ve come to enjoy the cohesive feel of building my view with what React calls components.
Does this answer your question? 
1 Like
Yeah I think this is actually a good appraisal of the main difference between Blaze and React - one forces you to separate your event handlers and helpers, the other just has JavaScript functions everywhere. Everything else is an implementation detail IMO.
2 Likes
This where I’ve been getting at, it’s just an implementation difference.
It’s really dissapointing for me to have to clearify my opinion like this, given your very limited response on the subject.
- Do you have a better distinction between components and templates that I could learn from?
- What do you feel more comfortable working with?
Your questions are great, but you’re not really contributing much in response for me to learn from, as I imagine you probably have a better insight?
My bad then. I thought I made my point.
I found your comment on the superiority of “components” over “templates” to be amusing since both Blaze and React have the same parts (a makup and the code that drives the markup). The fact that you can use full JS in the markup, or have everything in one file, is just an implementation detail. You still have the same elements, just arranged in a different way.
So even though they have the same parts, and you still have to do pretty much the same things to make a UI element, for some reason you think with React you’re working with “components” and with Blaze you’re working with “templates”.
As for a definition of a component, we can use the dictionary’s:
A software component is a unit of composition with contractually specified interfaces [and behaviors], and explicit context dependencies. A software component can be deployed independently and is subject to composition by third parties.
This implementation difference has a big impact on how well I manage to compose my views, and this does indeed make React superior to Blaze for me. I’m developing applications, and I care very much about this - I think this is important for anyone assessing what tools to utilize for a project.
Blaze has templates, React has components. This is not something I’ve decided for them, and making a distinction between them, it makes sense that they have different names, no? This comment is sooo far besides the point I was making.
Please, this has never been about what the word “component” means, but about how React’s view units allow me to do what I want to do - get stuff done!
I’ve answered your question, will you please actually look at what I asked you, and answer maybe one of them? That would be nice.
TLDR: You construct “components” with Blaze as much as you do with React. If you disagree then what exact definition of “component” are you using so that markup+code is a “component” React but not in Blaze?
This is precisely what I’m referring to. You’re using names arbitrarily. You haven’t explained why the markup in Blaze is a “template” and why the markup in React is a “component”. You seem to suggest that it’s because React embeds the markup in the JS, but when I asked if Blaze did the same would it then have “components”, you said no.
All you’ve said is basically “React is better than Blaze”. Which I agree btw. Feature by feature, it is demonstrably better than Blaze. That doesn’t mean there’s a fundamental difference between the two.
Please, this has never been about what the word “component” means
If you keep making statements like “Blaze has templates, React has components.” then it IS about what “component” means.
look at what I asked you, and answer maybe one of them?
What question didn’t I answer or address?
<template name='example'></template>
let example = React.createClass({
componentDidMount() {...}
...
})
I don’t think anything good will come of continuing this - we clearly don’t get each other, and that’s OK!
over & out
You still don’t get it. By your logic Blaze would truly have “components” had MDG chosen different verbiage:
<component name='example'></component>
btw, you still haven’t given a working definition of “component” to differentiate what you create with Blaze and React.
OK, it works!
I know the name “templates” will be confusing, but it’s the best way I could think of describing the idea. By the way, the code is based on Meteor’s own JSX compiler.
1 Like
I strongly disagree with all these React templates.
Popular argument is to reduce the learning curve for new comers.
So, then the answer is, help them to learn React
Other argument is you like templates a lot. Okay, then use a good template UI system like Angular or VUE.
React based templates leads no where.
5 Likes
What about stateless components? Or are you specifically against the word “template”, but not the concept?
Okay. Let me add a bit on this.
React is about JavaScript. That’s the reason why it’s getting so popular. Not just because of Performance or it’s came from Facebook. (This helps)
Being React Component is a JavaScript helps us to do a lot of things like:
- Simple Testing
- No need of helpers kind of things (in Blaze, Handlebars)
- Ability to manipulate with JavaScript (root for containers patterns and many others)
If we remove the JavaScript part from React, then it reduce the value of React.
Stateless Components are so good because it’s still JavaScript and we can do anything we expect to do with JavaScript.
Other argument React templates is, With React we need to do a lot of boilerplate code
But the truth is, it’s other way around. Yes, you may need to import React and other stuff on the top of the page. That’s for something else. (I highly recommend doing such imports)
But think, in Blaze also there was a lot of boilerplate code.
- When creating the template you had to wrap it with a
<template>tag. This is very similar to writing a Stateless component. - With helpers and events, again you had to write some JavaScript code. With React you don’t need to do that.
- In Blaze, we had to use
withto deal with objects. But in React JSX, it’s just javaScript. You can even use write sub components.
So learn some React, then write React the way it is. This helps you in the long run.
This is how I think about React
4 Likes
Wait, I’m not sure if you’re reacting to my proposal, or to the idea of templates in general. Because my idea is just Stateless Components with a very thin wrapper, I’m not trying to remove the JavaScript part of React in any way.
Yes. I get it.
You mean this right: https://github.com/SachaG/simple-todos-react-jsxt/blob/master/templates/TaskTemplate.jsxt
But the point is sometimes, we need to use React classes as well to make things manageable. That’s why I said all the above.