3 ms·

The JSX is not the same as it is encapsulated in the render() method withing the JS file. This is the whole point of why this implementation is not a separation

by kensign 11y ago

The JSX is not the same as it is encapsulated in the render() method withing the JS file. This is the whole point of why this implementation is not a separation of concerns. The view is essentially embedded in the controller in order to simplify how a controller passes scope to the view. This isn't the first time people have fallen prey to embedding HTML as a string into JS to write the DOM. 5/10/15 years ago, if we saw this, devs would just shake our heads. If anything React is an old hack, an anti-pattern brought forward again. I misspoke about views in business logic, as you said, it is the controller logic, which should be decoupled from the view itself as well. The naive example of converting a webcomponent to a JSX component may look similar, but more complex components will only require greater complexity for the render() method to handle. I understand your rationalization, but the crux of the arguments here are concerned with the anti-pattern React introduces and why developers who've come across this before have seen this as technical debt. The arguments for React are a matter of opinion, wherein the arguments against it are based on the practical principles for programming UIs, principles have been forged to be tried and true since the 70's. I personally favor standards, such as webcomponents and OO programming for modules. I understand that this may not seem popular at this point and time, but 20 years of dev experience has taught me otherwise.

vans 11y ago
I totaly agree with you. We need full decoupling between components. They have to be seen as pure functions, taking parameters and returning view modifications (and new values)
- madeofpalk 11y ago
  Stateless Functional Components in React! const ProgressMeter = ({ className, percentage }) => { const meterStyle = { width: `${Math.round(Math.min(Math.max(percentage, 0), 1) * 100)}%`, }; return ( <div className={cx('root', className)}> <div className={cx('meter')} style={meterStyle}/> </div> ); };
madeofpalk 11y ago
> 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.
- kensign 11y ago
  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/ 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.

by kensign 11y ago

vans 11y ago

I totaly agree with you. We need full decoupling between components. They have to be seen as pure functions, taking parameters and returning view modifications (and new values)

madeofpalk 11y ago
Stateless Functional Components in React! const ProgressMeter = ({ className, percentage }) => { const meterStyle = { width: `${Math.round(Math.min(Math.max(percentage, 0), 1) * 100)}%`, }; return ( <div className={cx('root', className)}> <div className={cx('meter')} style={meterStyle}/> </div> ); };

madeofpalk 11y ago

> 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.

kensign 11y ago
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/ 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.