3 ms·

It does indeed go against years of advice, but only if you look at it from too far out: (Note: I've minimal Angular experience so I won't comment on that. I'v

It does indeed go against years of advice, but only if you look at it from too far out: (Note: I've minimal Angular experience so I won't comment on that. I've spent the last year on React) The real problem is mixing business logic and presentation, not mixing HTML and JS. React is purely presentation & presentational logic (or should be, you can of course implement it poorly) For Presentation, the HTML and JS are always coupled, whether you have them in separate files or not. So in that sense, all React is doing is admitting a truth. While embracing the coupling of that mix, React is ALSO pulling out a lot of logic: React encourages one source of truth (the state is in one spot, and drives the markup, but you never consult the markup to determine the state). An error that is commonly seen in, for example, jQuery apps, is that some state is hanging around in application variables, while other times it's in the current markup state, and the app will consult the markup to see what's happening. That's not a built in jQuery problem, it's just a common problem of implementation. I'm not sold entirely on the React boat, but it does seem to directly address problems that I've encountered in other systems, and I expect whatever comes next will build from React principles rather than reject them.

marknutter 11y ago
> For Presentation, the HTML and JS are always coupled, whether you have them in separate files or not. Absolutely not. Back when we were all just using jQuery, you could run $('.some-class').myWidget() to activate a widget on any element matching the query. There was no need to couple the implementation of the widget with the element to which it was applied. If the widget had some internal element construction to do then yes, I would agree, it makes sense to have it be part of the same file, and this was often done with string concatenation back in jQuery days. However, there is still value in being able to share the same html template across multiple models. You may have a general tabular structure you want to adhere to app-wide but you may want to implement different dynamic logic to those tables in different places. Now you're faced with having to copy/paste the same template over and over in React to accomplish the same task, or you have multiple mixins that define different behavior which kind of defeats the purpose of having the logic and the markup live together.
- ergothus 11y ago
  > If the widget had some internal element construction to do then yes, I would agree ...which covers most everything, really. Also, in the React world, if you just need to manipulate the data passed into a component, that's all pure JS. Only the component itself (with a reference to the passed-in data) would be JSX, which is distinctly more friendly to work with than string concatenation. (and I say that as someone that hates having a build step) > However, there is still value in being able to share the same html template across multiple models. ... > Now you're faced with having to copy/paste the same template over and over in React I don't think you understand the concept of a React component, or I've misunderstood what you are saying. Make that template once and just use it wherever needed! I have some complaints with React, but lack of reuse and JSX being worse than the alternatives are NOT among them.
- btdiehr 11y ago
  > you could run $('.some-class').myWidget() to activate a widget So we have obfuscated the functionality embedded in our HTML with jQuery calls in separated files. Is this what you mean by decoupled? > Now you're faced with having to copy/paste the same template over and over in React to accomplish the same task, This is nonsense. Have you ever... used React? I recommend not opining on something which you lack even the most basic knowledge about.

marknutter 11y ago

> For Presentation, the HTML and JS are always coupled, whether you have them in separate files or not. Absolutely not. Back when we were all just using jQuery, you could run $('.some-class').myWidget() to activate a widget on any element matching the query. There was no need to couple the implementation of the widget with the element to which it was applied. If the widget had some internal element construction to do then yes, I would agree, it makes sense to have it be part of the same file, and this was often done with string concatenation back in jQuery days. However, there is still value in being able to share the same html template across multiple models. You may have a general tabular structure you want to adhere to app-wide but you may want to implement different dynamic logic to those tables in different places. Now you're faced with having to copy/paste the same template over and over in React to accomplish the same task, or you have multiple mixins that define different behavior which kind of defeats the purpose of having the logic and the markup live together.

ergothus 11y ago
> If the widget had some internal element construction to do then yes, I would agree ...which covers most everything, really. Also, in the React world, if you just need to manipulate the data passed into a component, that's all pure JS. Only the component itself (with a reference to the passed-in data) would be JSX, which is distinctly more friendly to work with than string concatenation. (and I say that as someone that hates having a build step) > However, there is still value in being able to share the same html template across multiple models. ... > Now you're faced with having to copy/paste the same template over and over in React I don't think you understand the concept of a React component, or I've misunderstood what you are saying. Make that template once and just use it wherever needed! I have some complaints with React, but lack of reuse and JSX being worse than the alternatives are NOT among them.
btdiehr 11y ago
> you could run $('.some-class').myWidget() to activate a widget So we have obfuscated the functionality embedded in our HTML with jQuery calls in separated files. Is this what you mean by decoupled? > Now you're faced with having to copy/paste the same template over and over in React to accomplish the same task, This is nonsense. Have you ever... used React? I recommend not opining on something which you lack even the most basic knowledge about.