With regards to Meteor (and Blaze specifically), how about Blaze React?
5 Likes
Can you point out some drawbacks of React except for mixing JS with HTML and CSS.
8 Likes
Did you check out Aurelia? … It seems they are heading where you are pointing ?
3 Likes
I don’t think React is hard at all? Can you maybe put some more words on this statement?
In regards to a singular new frontend language with more power, Elm is above and beyond anything I’ve seen anywhere else.
3 Likes
Respectfully, but fully, disagree. My code is cleaner & less error prone in react. If you’re writing a web app, you can keep CSS separate. If you’re writing for mobile, it doesn’t matter whether you use native, Cordova, Titanium, or React Native, you’re gonna combine these. The future is probably going to be web components (think Polymer), which also is following this pattern (but is IMO uglier than react). There’s nothing stopping react from adopting web components behind the scenes, so it’s pretty futureproof.
Now, just because everybody is doing it doesn’t make it right. But, the DOM is no longer static with a couple dynamic divs. Template languages work because they’re all just glorified string replacements, which work for simple things (if a A, else B) but things like a binary decision tree requires an easy-to-reason structure, which react enforces. Being forced to write clean code isn’t a bad thing! Sure, there’s a learning curve, but the right decision isn’t always the easiest 
13 Likes
I highly doubt they’re working on a complete replacement. They have too much in infrastructure tooling and mindshare to drop it. I do think it’ll change a bit over the years. Currently they can hire someone and have them productive in the first day.
I’ve talked to some of the React devs and basically in time the Object Oriented interface will sunset and a more functional approach will be the norm, as the JS community adopts FP over OO. Stateless components are the first step. Stateful functions/modules are next. Here’s an example of a spike of what’s coming in the future:
// react stateful module
function handleClick(props, state, event) {
if (event.button === 1) {
return { count: 0 };
}
if (props.onClick) {
props.onClick();
}
// state gets returned instead of using this.setState
return { count: state ? state.count + 1 : 0 };
}
export function componentDidMount(props, state) {
console.log('mounted');
}
export function render(props, state) {
return (
<div>
Clicked {state.count} times
<button onClick={this(handleClick)} style={{ width: props.width }} />
</div>
);
}
Replacing Redux functionality is something that I imagine is being experimented with too.
> Anyhow mixing HTML, CSS and Javascript in the same file is quite confusing, error prone and very verbose compared to Blaze or Jade. I know some people might disagree on this, but I want to ask them: what if there would be synthesis between thesis (Blaze) and antithesis (React), which would be a new grammar that encompasses both JS and HTML in a new, easier language, like what Jade or Mustache did with HTML and templating?
I agree with @mattkrick , i’ve found the opposite to be true. Having everything in one file increases cohesion.
Also you’re not mixing HTML with JS, you’re mixing JS with JS. JSX is just sugar that was originally meant for designers. React started out without it. The attributes that people complain about (like className) are the DOM API because it’s not HTML it’s the a representation of what the DOM should look like.
For example this is pure React and a JSX version, the JSX de-sugars to the first example:
// before
const MainView = React.createClass({
render() {
return (
React.createElement("form", formProps,
React.createElement("input", {ref: "email", type: "email"}),
React.createElement("input", {ref: "password", type: "password"}),
React.createElement("input", {ref: "submit", type: "submit"}),
React.createElement("div", {ref: "errMsg"}, this.state.loginErrMsg)
)
);
}
});
// after
const MainView = React.createClass({
render() {
return (
<form>
<input ref="email" type="email" />
<input ref="password" type="password" />
<input ref="submit" type="submit" />
<div ref="errMsg">
{this.state.loginErrMsg}
</div>
</form>
);
}
});
> Is there anything already moving in the direction of making React easier to use?
I’m hoping React itself will make it easy to share data across components without flux/redux. I think this is the main rub with building apps that are not simple.
I think a lot of people dismiss React without taking a day or two to learn it. They judge it based on a simple todo app and miss the big picture on how it helps you structure code on a real app.
14 Likes
I think React could learn a lot from Elms model for HTML, which in my opinion feels more natural, especially if we want to be functional.
2 Likes
We’re also judging it on W3C standards, quality of the API, existing tooling infrastructures outside of Facebook, and different market needs.
React breaks color coding standards in editors; the ‘props’ and ‘mount’ verbiage sounds like brogrammer gutter slang, we can’t scan/reuse HTML templates in non-react pipelines, web components aren’t being exposed according to W3C standards, and while the static imports might be great for file load ordering, they’re brittle and horrible for discovery-based application design.
The BlazeReact package solves most of these issues.
4 Likes
What does that even mean? 
2 Likes
Seriously…what does that even mean? Get your mind out of the gutter and stop bringing up syntaxes that have no bearing on if you should use something or not.
Babel does syntax highlighting for sublime
Atom:
WebStorm - JSX support built in
Web Components are not their flavor, and not the flavor of many popular UI frameworks:
I thought static imports were banned in strict mode for ES5? Not sure what that means.
BlazeReact may never be finished, as Tim Brandin is still questioning the upside of that project.
2 Likes
Thanks for the question, as replying to it forced me to better focus on what was the issue at hand.
I won’t bother you with the importance of separation of concerns, as many developers better than me already faced the question, but I will try to follow a more managerial outlook.
Right now you have some developers more experienced with front end (HTML/CSS), and some which works more with backend (JS, Databases, etc). The have different salaries, as this represents the fact that learning JS and backend stuff is an additional complexity.
When you mix JS and HTML you either need to drop the less experienced front end devs, or to teach them how to become front end devs.
Isn’t there a value in keeping things separated? This forum is filled with very very smart people, but not everyone is a full stack developer, and you are cutting out a large workforce by imposing this.
2 Likes
yeah, Aurelia and Elm are really interesting, but I was hoping to improve my Meteor skills before jumping on the next bandwagon. If you keep jumping, you learn nothing 
, but aurelia now that is out is definitely worth checking.
Same thing for Elm, before I will learn any new language I want first to master the new features of JS.
As a Jade (and Coffeescript) user my plan is to use react-jade when 1.3 modules will work to have a Coffeescript file and a Jade file for my React client pages.
3 Likes
some very good points as usual
Facebook has done it before and I personally think it’s a good management practice to start over once the project has become too bloated.
Facebook totally dropped HipHop for HHVM, and did similar things with their API in the past. You can’t know everything at the beginning of a project, and when you gain said knowledge it seems faster to re-architect your project rather than force unplanned features in it.
I’m not speaking of breaking changes, but syntactic sugar like what mustache has been for HTML.
But don’t you think that respecting the separation of concerns principle would help many noobs developers to enter the world of Meteor and React?
True. I will try to master React, since so many people sponsor it. Then maybe I will refuse to use it, but I need to master it first.
1 Like
It means there are women in the audience; and that not everybody who uses Meteor thinks like a 20-something male programmer trying to emulate Mark Zukerburg.
Look, I’ve been programming for 30+ years, and have programmed in dozens of languages. Did IBM and Microsoft systems for a long time, so I’m familiar with what well designed APIs look like.
And the simple fact of the matter is that there’s been a marked decline of late of the quality and professionalism in the API design and language included in the examples of the broader Meteor community. ‘props’ is just one of the many terms creeping their way into the API that makes the platform sound like it was developed by a bunch of brogrammers. Fine. Whatever.
But there are some of us who don’t want that kind of slang in our APIs. Because we’re selling into ambulance dispatch centers, genome sequencing labs, emergency rooms, and intensive care units. Blaze has a squeaky clean API, and we have a right to hold other technologies up to its standard.
So when we ask the question ‘what can MDG do to make React better?’, one of the responses coming from the community is ‘clean it up and make it more professional’.
Facebook is not a shining example of professionalism, what with Zukerburg and his hoodies and his ‘move fast and break things’ mentality. That doesn’t fly in the healthcare or finance industries.
6 Likes
It’s pretty much already finished. It’s definitely usable for our purposes, and will be going into the Clinical Meteor track in all likelihood.
4 Likes
Perhaps. But only if the beginner has been told that using div in your JavaScript is a bad thing. When building a React Native app there are no qualms about using <View> and <Text> or inline styles because there isn’t dogma stating that Objective-C is kept out of the UI file. However, these are both the same thing if you swap View for div.
This ‘rule’ started when we had a giant HTML page, and it made sense then. Web components are the future for ‘building apps’ and a React component encapsulates everything it needs in one little component that are composed to make a big page (as opposed to one large page).
IMHO, we’re starting to build more ‘apps’ now a days and using patterns that desktop and mobile apps have been using for years makes more sense than trying to hold rules/practices made when building “HTML” webpages.
We’re doing things with HTML that it was never intended for, which is why we have so much pain when comparing it to building an iOS app for example.
If anything I think that having a beginner use React, Elm, etc… Will guide them to be a better developer by thinking about things in a functional and declarative way. Again, just an opinion. Blaze could have done this, but failed to push devs into building great apps that won’t crumble (like @awatson1978 apps, they’re a great example of Blaze done well. The other resources… Not so much).
True. I will try to master React, since so many people sponsor it. Then maybe I will refuse to use it, but I need to master it first.
Yeah, I think learning it and contrasting what makes it different than Backbone or Ember 1.x will be eye opening. I’ve heard lots of great things about https://reactforbeginners.com for those who want a fast one stop place to learn.
3 Likes
I thought about Aurelia as replacement of Blaze/React… but then again, I dont knot much about Aurelia and it seems more than just that…
I don’t think there’s anything wrong with props (as short for properties) or saying that a component can be ‘mounted’ in a view.
I don’t see how React is going to get any better by replacing terminology you find offensive.
Unlike you, I have less than 3 years of experience studying CS, but you’re not even talking about CS, but instead misinterpreting and applying your own sexist views…
I don’t want to read about your sexist attitude towards male programmers… I just want to learn about cool tech 
plz
7 Likes
Agreed. And to reiterate what I’ve stated elsewhere, I do in fact think that functional programming is ultimately the right way to go for the Meteor view layer. @SkinnyGeek1010 is definitely on the right track with all the work he’s been doing.
Thank you for the acknowledgement, by the way. Not trying to sling mud. Quite the opposite. Just trying to raise the standards, and give some tangibles on how MDG can help improve React. At least from the perspective of the industry I work in.
4 Likes