6 ms·

It's because it flew in the face of commonly accepted best practices. It felt like a return to PHP/ASP days of old. But in reality, once you use it, you realize

It's because it flew in the face of commonly accepted best practices. It felt like a return to PHP/ASP days of old. But in reality, once you use it, you realize it's not that. It's a good abstraction. It puts concerns in the right place. Now, when I have to write something in any .erb file, it's like pulling teeth. JSX + React is a very good view-layer and component abstraction.

ashark 9y ago
I'm not even saying it's a bad idea, just that I think it's entirely understandable that people are a little confused and upset that a decade plus of best practices suddenly did a 180 and they're being looked down on for even taking a second to go, "wait, what?"
- chrisco255 9y ago
  I guess these arguments feel a bit dated at this point. React has been out for four years now.
- orclev 9y ago
  Part of what's missing is that separation of concerns doesn't mean not mixing code and markup, it means not mixing your business logic with your rendering logic. One way of enforcing that is to put your rendering logic into a straightjacket and restrict it to very very simple primitives, nothing more complex than a simple for loop over some indexed value or a very primitive form of if/else statement, which is basically what most of the templating systems do. That forces you to keep your business logic out of the view logic because the view rendering system simply isn't powerful enough to express most of your business logic. It turns out though that when you do that, it becomes really hard to express some more complicated (but perfectly valid) view logic, and then you end up moving a bunch of your view logic down into your business logic which is the same problem, just in the other direction. JSX takes the straightjacket off and gives you the full power of JS to express your view logic. Yes, it also opens the door to let you do bad things like in-lining all your business logic inside of your views, but realistically nobody is doing that, and the framework strongly discourages doing things like that.
- yen223 9y ago
  This is the unfortunate result of people following "best practices" only because that's what other people do, and not because of some justifiable benefit of said practice.
seanwilson 9y ago
> It's because it flew in the face of commonly accepted best practices. People need to stop blindly following current "best practices" because they change all the time. Weigh up the pros and cons yourself. I personally don't see any difference with doing a loop in JSX and doing a loop in HTML using special tag attributes. Best practices for web app UIs have changed dramatically as we've went from e.g. server side only logic -> jQuery/AJAX based UIs -> Backbone -> Angular 1 -> React. This clearly shows we've no idea what the "best" way to do things is yet.
- root_axis 9y ago
  > I personally don't see any difference with doing a loop in JSX and doing a loop in HTML using special tag attributes. Don't do that. Perform loops outside of the final template. People get confused because they don't remember that JSX is just a tree of nested React.createElement function calls, so they decide that they should mix looping logic into a block of JSX because that's what they'd do in PHP even though you'd obviously not do that when looking at raw code. const MyComponent = (props) => { const itemList = props.itemData.map((itemData) => { return <Item data={itemData}/>; } return <div><h1>List of items</h1><br/>{itemList}</div>; } It's as simple as that. There is never a reason to mix logic into the "template" part of the component.
  - seanwilson 9y ago
    I'm not seeing a huge difference. It's a bit cleaner, similar to how it would look if you did a similar refactor of plain JavaScript code, but it's still very similar. If the logic is short, it's cleaner to inline it sometimes. Going back to my comment, what are the pros and cons or is this just separation based on principle?
  - dwaltrip 9y ago
    Do you have any specific reasons for why `items.map` should not be inside a jsx tag? Your comment doesn't make it clear why you think this.
    - 9y ago

ashark 9y ago

I'm not even saying it's a bad idea, just that I think it's entirely understandable that people are a little confused and upset that a decade plus of best practices suddenly did a 180 and they're being looked down on for even taking a second to go, "wait, what?"

chrisco255 9y ago
I guess these arguments feel a bit dated at this point. React has been out for four years now.
orclev 9y ago
Part of what's missing is that separation of concerns doesn't mean not mixing code and markup, it means not mixing your business logic with your rendering logic. One way of enforcing that is to put your rendering logic into a straightjacket and restrict it to very very simple primitives, nothing more complex than a simple for loop over some indexed value or a very primitive form of if/else statement, which is basically what most of the templating systems do. That forces you to keep your business logic out of the view logic because the view rendering system simply isn't powerful enough to express most of your business logic. It turns out though that when you do that, it becomes really hard to express some more complicated (but perfectly valid) view logic, and then you end up moving a bunch of your view logic down into your business logic which is the same problem, just in the other direction. JSX takes the straightjacket off and gives you the full power of JS to express your view logic. Yes, it also opens the door to let you do bad things like in-lining all your business logic inside of your views, but realistically nobody is doing that, and the framework strongly discourages doing things like that.
yen223 9y ago
This is the unfortunate result of people following "best practices" only because that's what other people do, and not because of some justifiable benefit of said practice.

seanwilson 9y ago

> It's because it flew in the face of commonly accepted best practices. People need to stop blindly following current "best practices" because they change all the time. Weigh up the pros and cons yourself. I personally don't see any difference with doing a loop in JSX and doing a loop in HTML using special tag attributes. Best practices for web app UIs have changed dramatically as we've went from e.g. server side only logic -> jQuery/AJAX based UIs -> Backbone -> Angular 1 -> React. This clearly shows we've no idea what the "best" way to do things is yet.

root_axis 9y ago
> I personally don't see any difference with doing a loop in JSX and doing a loop in HTML using special tag attributes. Don't do that. Perform loops outside of the final template. People get confused because they don't remember that JSX is just a tree of nested React.createElement function calls, so they decide that they should mix looping logic into a block of JSX because that's what they'd do in PHP even though you'd obviously not do that when looking at raw code. const MyComponent = (props) => { const itemList = props.itemData.map((itemData) => { return <Item data={itemData}/>; } return <div><h1>List of items</h1><br/>{itemList}</div>; } It's as simple as that. There is never a reason to mix logic into the "template" part of the component.
- seanwilson 9y ago
  I'm not seeing a huge difference. It's a bit cleaner, similar to how it would look if you did a similar refactor of plain JavaScript code, but it's still very similar. If the logic is short, it's cleaner to inline it sometimes. Going back to my comment, what are the pros and cons or is this just separation based on principle?
- dwaltrip 9y ago
  Do you have any specific reasons for why `items.map` should not be inside a jsx tag? Your comment doesn't make it clear why you think this.
  - 9y ago