5 ms·

We went from anything like JSX getting you laughed out of the room (LOL 'onclick' properties, hello, 1998 called! Also code doesn't belong in markup, so markup

• christophilus 9y ago
  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
• ageofwant 9y ago
  JSX is not html. JSX is not a templating language. The similarity between JSX syntax and the equivalent virtual DOM node names is the reason it exists. When you write JSX code you are writing javascript code using the JSX DSL to generate the virtual dom. 'HTML templates embedded in code' is simply not what happens when you use JSX. The fact that you got fooled into thinking that is the opposite of a DSL problem.
  • ashark 9y ago
    > The fact that you got fooled into thinking that is the opposite of a DSL problem. Which part of what I wrote makes you think I think JSX is an HTML template? The part where I specifically called it "not-html" and the react.createElement code it's translated to "still-not-html"? That it's kind-of-HTML-but-not, turned into Javascript, turned into shadow-DOM transformations, turned into HTML, is Rube-Goldbergian enough to warrant skepticism. No need to misunderstand it to feel that it's an indication that something somewhere has gone deeply, fundamentally wrong. And actually I think it'd be fair and consistent to call it a template language, were I inclined to press that point. That it becomes Javascript doesn't change the form it takes when you're writing it. Looks and quacks enough like a duck that insisting it's totally not a duck at all is untenable. Sure, it's translated into shadow-DOM-transforming JS. So? It's not like HTML itself doesn't go through some intermediary representations before becoming different colored glowing pixels on your screen.