React also has sort of “Separation of Concerns”. Just that it is not divided in between different files, rather it is divided within different functions in the same file. Although it confused me a lot in the beginning, just because I was never used to it, then it really felt like simplifying a lot of things for me. Most important of them is just that I didn’t need to go try to find that “helper” function to return me something, or the “event” function to fire what I want. Yet trying to couple them still gives me a headache in my Blaze project.
But I absolutely agree Blaze should remain supported somehow, and whomever’s wishes to stick using Blaze for any reason shall be regarded totally legit and respectable.
We evaluated React for our project but after a lot of research we decided it’s not for us. There are a lot of downsides but the main one is our designers need a Jade like templating language. First, seriously, who would go back to the dark ages of plain HTML after years of using HAML, SLIM and Jade. Programming tags directly in Javascript or Hyperscript would also not work for our designers. It makes me think React users don’t love design (Facebook itself surely doesn’t, haha!). Also, React.js itself lacks beauty, but maybe I find that important because I come from the Ruby community (where ugly code is bad code).
Concerning Blaze, version 1 is very verbose and outdated in their concepts. And sorry, I don’t believe in a community created version 2 that lives up to the demands of today.
So that leaves us with Angular… We will evaluate Angular when version 2 is released. We hope it’s a better match. We evaluated Vue.js and it’s one of the better options, however it’s a 1-man team and it’s not one of Meteor’s “officially supported” view layers. That’s too bad.
I gotta be honest that React may cause you to gag initially but ultimately it’s super liberating to just deal with the updating the state and having the UI update accordingly.
That’s really what the main benefit you get with React.
Are there other alternatives? I suppose Riot is one, but it’s nowhere near as popular, and popularity is king.
I have to say I’m kinda tired of the “Separation of Concerns” whining as well.
What concerns really need to be separated? Languages? Why? I really can’t see a logical reason to separate different language pieces. That’s illogical to me. That’s not a “concern”, it’s tooling.
It’s like saying you can’t have a hammer and pliers in the same toolbox. Wtf?
The actual concerns you want separated are features, functional pieces of your app.
You don’t want the header on your page to meddle with the content section and vice versa…
That’s components! And that’s exactly what React was designed to do, and what Angular 2 is trying to get to.
I’m not a fan of React, but I do support the component approach to structuring your views.
I feel like people who make the “separation of concerns” argument have probably not tried to actually write any code with React.
Also, a fad doesn’t last this long, so I think everyone can just stop hoping it goes away.
I can understand just not enjoying it (after actually trying it), just like you can like/dislike any other technology. But separating out html/js/css isn’t a big deal with react and no reason to disregard it.
Templates are on their way out, it just doesn’t compare to the productivity of a good component based framework with proper separation of concerns (which sometimes people confuse with separation of technologies and languages).
This was the biggest objection I had as well. Reality though is that I’m sure if you did some digging or did some work of your own, you could get a HAML like syntax that would emit the same object tree that JSX emits. The API that JSX compiles to is not that complex. For me I wanted to use plain HTML as the designer on my team provides ready made layouts with HTML/CSS and I just tack UX onto them.
This is really purely an opinion. React users are a huge spectrum and design is central to their operation in a lot of cases. Facebook is certainly lacking in certain areas of “design” but they have really come around in that area as they have grown. They just continue to approach it from an application perspective instead of a web perspective, which means it makes more sense to them as program design to go the React road.
I somewhat disagree here. Blaze version 1 did a lot of things right and lived up fully to the stated goals. I just don’t think that MDG realized how far it would be stretched. I think a quality version 2 could happen especially if (as some have proposed) it ended up wrapping another view layer and became just a templating construct.
That’s kind of too bad you see that as your only option. Angular 2 while awesome looking is still a long way off. The delay in Angular 2 is the primary reason our team went to React. We couldn’t wait any longer to start the move off of Blaze, and Angular 1 felt to be just as “old school” as Blaze.
I have to agree here, React seems to be very straightforward. The component level construction makes a ton of sense. If your component crosses some complexity threshold, break it down!
I’ll admit I did get caught up in that whining early on myself. I do come from an old school background (been programming for the web for almost 12 years, and remember when CSS showed up and changed everything! The simple fact though is that this whining comes from people who think about javascript as simply providing some interaction “fluff” on top of HTML. They forget that even with Blaze, HTML is no longer being built on the server and sent over the pipe. Anything that isn’t 100% pure HTML already violates the “separation of concerns” that they are trying to claim. So Handlebars, Knockout (those were the days) Blaze, Angular, React, JSP, Jade, ASP, PHP, etc all violate that claim. Honestly we haven’t had pure HTML in so long I don’t think anyone doing this complaining even knows why they are complaining. The reality is we have come to a point where we are building enough complexity client side that the time has come to reassess where we draw those lines. React and Angular 2 are both making the same decisions here, so get over it people!
Simply put, yes. I stopped making that argument when I used Flow Components on a project. Thinking in terms of components, I quickly got frustrated that my HTML was in a separate file from my logic. They are very related, and the same concern at that point. I will admit I have times when I want them separate. When what I’m doing in the component is building a model to be displayed and then the HTML is just to display it. However if that is how you are dividing that particular area, then there is something really cool for you to use: Higher order components. Build your beautiful model and emit it as a property! Then provide the model to the child component to do with as it pleases! Boom, separation of concerns without lying to yourself that you are “writing HTML” because you aren’t!
While I agree in general, there are times where I have just a ton of DOM for very little content. This is when templates make sense. Why write long complex JSX with looping constructs and such when I can use a template. It is for that reason that I made the atmosphere package for React Templates. It is not that I like templates more, but sometimes I don’t want to have my long verbose mostly filler dom for ancient browser compatible rendering contain javascript functional loops and ternaries. I want it to be clean looking and easy to read. One example that I constantly go back to is a navbar. I could make a navbar where each dropdown is a component, and each option is a component, and so on and so forth, but usually a navbar is relatively static, and even when data driven, it is a relatively straightforward mapping of data to dom, but there is usually a lot of dom for a navbar that remains compatible with IE9.
So for that reason, I’d rather have a template at that point with a looping structure. Dive in further in the actual app pages, and I almost never would use templates. So while they are on their way out, they I think will always have a place where the task would be well served by a template.
I really think the only thing holding Blaze back is a logo. We need something cool, something fresh … we can’t copy React’s logo, that’d be crazy! Wait, you know what - Atom has a really cool logo. Maybe we can come up with something cool using Atom’s logo for inspiration … I wonder …
It doesn’t. The two are completely different questions. There is no difference in the reusability of your code if you use JSX in the same file, or have a second file which compiles a function to include. In both cases, you package the lot up as a bundle to be exported. React still sees the lot as a single React Component Class while your local code knows that for the render routine, it’s outsourcing that to another file.
You can use call to bind this in your render function so that for all intents and purposes, the template is just one step removed from your actual render, not some arbitrary function out in the middle of nowhere.[quote=“hwillson, post:29, topic:21846, full:true”]
I really think the only thing holding Blaze back is a logo. We need something cool, something fresh … we can’t copy React’s logo, that’d be crazy! Wait, you know what - Atom has a really cool logo. Maybe we can come up with something cool using Atom’s logo for inspiration … I wonder …
[/quote]
Silly me, I would have thought that the meteor trail was the logo for blaze, of course it needs it’s own… I know, let’s make a meteor out of handlebars tags!
Ok, no, probably not. I don’t think that blaze needs a logo as much as it needs to embrace the component architecture that is invading the web (in a good way!)
I think using React makes me a better JavaScript developer, where as Blaze made me a better Blaze developer. Both are fine, but even if React goes away the skills it’s taught me will still have value.
You don’t need React to be a good JS developer. React is an abstraction layer. Blaze is an HTML templating engine. Straight to the DOM. If you really want to be a good JS developer, courses is the way to go, not a UI library.
@M4v3R you’re really on to something here! I think we need a little more personality though; the React logo is a bit cold and direct; I know flames are hot so we’re headed in the right direction but we need a little more character. We need to show the Reactors that while they mean business, we mean warm and fuzzy. Wait, I’ve got it - we need Blaze Guy!
React is simple productivity hack, which is offered as revolutionary advancement. It’s nowhere close to framework. And JSX is nothing new, it is on the same level as LESS/SASS for CSS.
It’s just the other way - LESS/SASS are pre-processors so that human is eased in its work, machine does everything else. React’s JSX are actually as if you are doing the work of machine making post-processor output.
So in reality all that noize about revolution and componentinization React brings is simply bubble. It is just linker code, which is written by humans now
Hey @lassombra, your Meteor package of react-templates is pretty cool! Props! For me, the difference in readability of the react-templates examples vs. the generated code says enough (yes, I know generated code is not the same as human written code or the JSX version).
How much work do you think would adding Jade support be? I’m an advanced developer but I guess intermediate in the Javascript ecosystem?
Ember is nice and seems to be a heaven for very conservative guys. But it is not even close to the vibrant community of Meteor both in discussions and number of packages available.
this is a meteor build plugin that uses someone else’s node module. While I understand the foundation of that module, it would be quite involved to write a full parser myself.
I don’t know Jade, at all I’ve seen a few examples of it, but have no clue where to even begin!
I would totally be cool with collaborating though if a few people wanted to maybe fork the node module, add jade support, maybe also add an else construct? I just wouldn’t have the free time to do it myself. If you know some people who would like it, let’s all get together (slack perhaps) and discuss if we want to / can do this!
. We need a logo for Blaze! Here’s my take (full disclosure: I am NOT a designer, so if it’s really bad then just discard it):
