Hacker News Reader

Comment by ashark | Hacker News Reader

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 certainly doesn't belong in code, are you insane? Templates! Separate style!) and sensible, healthy skepticism of workflows like "compiling" not-html to still-not-HTML to eventually generate HTML at runtime, to all of that being just fine and anyone not immediately on board with it being called a moron seemingly overnight, I guess because Facebook says it's fine?

Some people have a little whiplash from all that, and I think it's understandable.

View on HN

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.

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?"

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.

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.

I guess these arguments feel a bit dated at this point. React has been out for four years now.

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

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

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?

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.

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

Basically what I'm saying is, if you were just writing React.createElement function calls, it'd be more obvious that the items.map should kept out of the rendering code, e.g.

    const MyComponent = function MyComponent(props) {
        return React.createElement(
            "div",
            null,
            React.createElement(
                "h1",
                null,
                "List of items"
            ),
           React.createElement("br", null),
           props.itemData.map(function (itemData) {
               return React.createElement(Item, { data: itemData });
           });
        );
    };

Of course, this is a simplified example, but the more complex the template (i.e. the deeper the nesting) the more the code benefits from having loops and other control structures extracted from the final template.

When a programming expression is made significantly more concise via some abstraction, it can be used in new ways that weren't reasonable before.

JSX makes expressing dynamic, declarative DOM markup concise enough that a short expression such as: `items.map(item => <FooItem item={item}/>` is no longer overly obtuse/obfuscating.

If the `map` expression becomes much larger, it might make sense to refactor it out in some way. But I would argue that the important guiding principle here is readability and modularity. Drawing a hard line between flow/control structures and "template code" is not useful, in my mind.

As others have stated in this thread, the more useful distinction is between business logic and presentation. Loops rightfully exist in both of those domains.

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.

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

Reply on news.ycombinator.com