To be fair, writing if statements in JSX is messier than it should be, but this is the fault of JavaScript and not JSX. If statements don't return anything, so we have to either create an immediately executed anonymous function (like you showed) or use a ternary operator. I'm pretty sure the author knows that you can put if statements in JSX but is frustrated that it requires boilerplate, which I think is a valid criticism. That being said, I greatly prefer using plain JavaScript over custom DSLs like Mustache.

I can see that. I just wasn't sure, because every time a React debate gets kicked off, I inevitably see the "doesn't support if-else" thing get brought up, and having finally worked through a MWE with it, wasn't sure if it was just the (somewhat) convoluted syntax or whether I was missing something bigger.

Yeah, it's possible in React do to it. But compare that to how Vue handles conditionals:

    <template>
    <div>
        <h2>HELLO</h2>
        <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p>
        <p v-if="location.query.home">You specified a home query: {{location.query.home}}</p>
        <p v-else>No home query was specified </p>
    </div>
    </template>

I don't know about you, but to me this code is 100% more readable than the React example you gave.

This is how I've come to write that in React, after giving up on attempting to find a consistent way to write ternaries which I would find acceptable when revisiting them (it just never happened):

    let Home = ({location}) => <div>
      <h2>HELLO</h2>
      <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p>
      {!location.query.home && <p>No home query was specified.</p>}
      {location.query.home && <p>You specified a home query: {location.query.home}</p>}
    </div>

I usually put all the possible negative cases first because outside of micro-snippets they tend to be short and sweet compared to the positive condition.

It's strange to me to embed conditions in attributes - particularly the v-else case in a different tag. It requires several visual scans of the block of code to determine what's going on.

In my opinion the following requires less cognitive overhead:

    function Home(props) {
      var query = props.location.query.home ?
        ( <p>You specified a home query: { props.location.query.home }</p> )
        : ( <p>No home query was specified.</p> );
      return (
        <div>
          <h2>HELLO</h2>
          <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p>
          {query}
        </div>
      );
    }

This also works:

    function Home(props) {
      return (
        <div>
          <h2>HELLO</h2>
          <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p>
          {
            props.location.query.home ?
              ( <p>You specified a home query: { props.location.query.home }</p> )
              : ( <p>No home query was specified.</p> )
          }
        </div>
      );
    }

What bothers me about this and other templating is that branching is so inconspicuous and therefore hides its complexity . Lets takes this extended example:

  <template>
  <div>
      <h2 class="c-section-heading">HELLO</h2>
      <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p>
      <p v-if="location.query.home">You specified a home query: {{location.query.home}}</p>
      <a v-else v-on:click="specifyHomeQuery" class="u-warn">No home query was specified</a>
  </div>
  </template>

And compare it to:

  <template>
  <div>
      <h2 class="c-section-heading">HELLO</h2>
      <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p>
      <p>You specified a home query: {{location.query.home}}</p>
      <a v-on:click="specifyHomeQuery" class="u-warn">No home query was specified</a>
  </div>
  </template>

The first one creates a div with 3 children with the type of the last one depending on the condition. The second one creates a div with 4 children (and a warning in the dev console). Both have 4 lines between the <div> with the same content except for two attributes on two elements and are indented the same by convention of the framework. They look nearly identical when quickly parsing over them but results are very different.

Compare this to the other react solutions, or my personal favorite:

  const Home = ({location}) => <div>
      <h2 className="c-section-heading">HELLO</h2>
      <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p>
      {location.query.home
    	  ? <p>You specified a home query: {location.query.home}</p>
          : <a onClick={specifyHomeQuery} className="u-warn">No home query was specified.</a>}
  </div>

I think it's pretty clear which "templating system" better represents the fact that this has more complexity than just a simple, linear component.

Mixing tag and conditionals in attributes is so messy, I don't know how people accept that. It messes with the level of the scope, you can't quickly see that only one of the <p> will be outputted.

Although I am admittedly fairly green when it comes to using React (full disclosure, I use Flux to manage state), I am unsure as to why you would NEED or want to handle conditional forks within the view itself.

My understanding of React was that conditions such as this should be handled by whatever is managing the state of the component, be it a method call within your view that alters your the local state, or a store based system such as Flux/Redux where the state is handled outside the view itself. Part of what makes React a beautiful framework (to me) is the concept of a state which controls what is rendered. Controlling what is rendered directly from the render method in the view seems to defeat one of the purposes of using a stately framework such as React in the first place. Sort of a cart-leading-the-horse situation.

Again, though, I am new to this framework (and JS frontend development in general) so please feel free to correct me.