> The JSX is not the same as it is encapsulated in the render() method withing the JS file.
I'm not quite sure what you mean by this.
Anyway, I can't help but think that the distaste of the way React does stuff is due to first impressions and not actually using it in a meaningful way. I get where you're coming from - when I first saw React I thought the JSX was a terrible idea, raising many of the same concerns you have. I'm not sure what your experience is with it, but I definitely didn't like the syntax at first. Also, although we are talking about react specifically, usually you'll be using other libraries along side to it handle the other non-viewy type stuff.
But then I actually used it, and lead a reasonably sized team to create a non-trivial web app with it. People who have been programming since before I was born, and people who learnt React for this project. Not all of them love it, but everyone is very productive with it and we all see the benefits it brings and we haven't been burned by some 'anti pattern'.
Traditional programming common sense still applies here: bad developers are going to write bad code. When something gets too large, take another look at the problem and perhaps break it down into sub functions. If you're repeating thinks, create a common module for it. Nothing really revolutionary about that.
I'm not convinced there's no one working on or with React who's seen the pain of poor separation of concerns. There are lots of smart people working on React, both at Facebook and in the community, who are just as aware of the programming. "principles [that] have been forged to be tried and true since the 70's"
Additionally, the Aurelis example we both mentioned isn't a webcompoent. It's as much of a web standard as React is.
What I meant by the difference between the HTML in an Aurelia template and JSX is that the React component's markup has to be inside the its respective controller's render() method. That's the main issue.
I am not arguing about JSX syntax, but rather the principle behind it. How would I safely refactor a css class across hundreds of components in a safe way and not by find/replace? An IDE such as WebStorm actually tracks CSS classes by their reference in other HTML/CSS files and this includes CSS preprocessors. I know it's a safe bet to run the renaming, although I always preview the changes beforehand.
I'm a reasonable developer, but this is an anti-pattern that has been eschewed voraciously over the years. Your appeal to the intelligence of React's devs is an informal fallacy and doesn't change this fact.
I am not trying to be dogmatic here. Yes, breaking the 'rules' when it is warranted is perfectly fine. My argument here is that in this case, this anti-pattern isn't warranted and will be very expensive work with as the product grows. I am advocating standards and best practices. React sidesteps both for an unnecessary reason. It works, it's pretty awesome how fast it is, but it cannot scale with a product's lifecycle.
Web components keep the HTML in the DOM and are being officially adopted as a standard. They can be polyfilled with a lib from http://webcomponents.org/. Aurelia, although it is a framework, is extremely lightweight and greatly simplifies the use of web components. Polymer isn't as elegant, but it clearly demonstrates the idea of dynamic reuse. There are other alternative libs as well.
As an aside, ES6 is now standard and with Babel. Javascript is now closer to ECMA, as it was intended to be.
I think I've made my argument as clear as I can, thank you for a great (and polite) discussion. It has actually been helpful for me to voice my opinion and get a better understanding of the support behind React. Again, it's impressive how fast it is over other libs such as jQuery, but jQuery's always been bloated and is near the end of its usefulness. However that point doesn't detract from the very cool things that React can do in the right hands. I wish I could bet on it, but to me it's the wrong horse in the race.
I'm not quite sure what you mean by this.
Anyway, I can't help but think that the distaste of the way React does stuff is due to first impressions and not actually using it in a meaningful way. I get where you're coming from - when I first saw React I thought the JSX was a terrible idea, raising many of the same concerns you have. I'm not sure what your experience is with it, but I definitely didn't like the syntax at first. Also, although we are talking about react specifically, usually you'll be using other libraries along side to it handle the other non-viewy type stuff.
But then I actually used it, and lead a reasonably sized team to create a non-trivial web app with it. People who have been programming since before I was born, and people who learnt React for this project. Not all of them love it, but everyone is very productive with it and we all see the benefits it brings and we haven't been burned by some 'anti pattern'.
Traditional programming common sense still applies here: bad developers are going to write bad code. When something gets too large, take another look at the problem and perhaps break it down into sub functions. If you're repeating thinks, create a common module for it. Nothing really revolutionary about that.
I'm not convinced there's no one working on or with React who's seen the pain of poor separation of concerns. There are lots of smart people working on React, both at Facebook and in the community, who are just as aware of the programming. "principles [that] have been forged to be tried and true since the 70's"
Additionally, the Aurelis example we both mentioned isn't a webcompoent. It's as much of a web standard as React is.