4 ms·

> 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

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

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.