Very very poor reasoning. I have never thought to myself, man I wish this wasn't JSX and just normal Javascript, to myself in the 6 or so years I've been using React. It just isn't something that anyone should care about and it shows the author has probably been biased against React forever, for no good reason.

> rather than bits of JSX just popping up everywhere here and there.

I did see lots of codebase write jsx like this. So I hate it. I starts the journey of front-end from jquery, ejs, angular.js, react to vue. And jsx of react always feels like a bad step to me.

Yes, If you write jsx properly, then it is just as readable as a normal template. But somehow some people never get it. And react also never made any attempt to stop insane codebase like this to exist.

(And you'd better pray your previous codebase owner isn't one of these, or you are in a big trouble)

In valid ES, you have many options even if none is perfect.

With the "horrible" ternary operator:

    const TodosList = ({ todos }) => (
      <div class="todo-list">
        {
          (todos.length > 0)
            ? todos.map(t => <Todo key={t.id} todo={t} />)
            : <p>No todos yet</p>   
        }
      </div>
    );

    const TodosList = ({ todos }) => {
      let todoContent;
      if (todos.length > 0) {
        todoContent = todos.map(t => <Todo key={t.id} todo={t} />);
      } else {
        todoContent = <p>No todos yet</p>;
      }
      return (
        <div class="todo-list">
          { todoContent }
        </div>
      );
    };

    const TodosList = ({ todos }) => {     
      if (todos.length > 0) {
        return (
          <div class="todo-list">
            { todos.map(t => <Todo key={t.id} todo={t} />) }
          </div>
        );
      } else {
        return (
          <div class="todo-list">
            <p>No todos yet</p>
          </div>
        );
      }
    };

    const renderTodos = (todos) => {
      if (todos.length > 0) {
        return todos.map(t => <Todo key={t.id} todo={t} />);
      } else {
        return <p>No todos yet</p>;
      }
    };
    const TodosList = ({ todos }) => (
      <div class="todo-list">
        { renderTodos(todos) }
      </div>
    );

    const Todo = (todo) => (
      <div class="todo">
        {todo.status === 'UNFOOABLE'
           ? <UnfooableError todo={todo} />
           : todo.size === 'GIGANTIC'
             ? <TextBox value={todo.body}>
             : (
                 <div>
                   <p>I've run out of creativity but just imagine this has more stuff</p>
                   <p>And that there's a good reason not to make this its own component</p>
                   <OneLineTextBox value={todo.body} />
                 </div>
               )
        }
      </div>
    );

To me it sounds as if you just didn't like JavaScript: the statement vs expression distinction constrains all non-JSX code too, e.g. you need to use the ternary operator to conditionally assign a value to a const variable.

Similarly, your example functions have long multi-line expressions as bodies so for the small gain of not needing the curly braces and a return statement, you pay a huge cost of not being able to use any statements in your code.

No, all four are fine and most people use them in code all the time. They're not completely identical to ternary operators because they move the location of the JSX outside the place where it's used, which can make it harder to read the code at a glance.

> it sounds as if you just didn't like JavaScript

Yeah, I see that as a failure of EcmaScript, as I said in the first comment. JSX has to work within the unfortunate boundaries of the language.

> for the small gain of not needing the curly braces and a return statement, you pay a huge cost of not being able to use any statements in your code

That wasn't intended to be a meaningful part of the example, I was just writing the shortest component that let me show a particularly style which would be nice to have in EcmaScript instead of ternary operators.

Yes, this is a key point. Indeed, many other 'constructed artifacts' compose nicely as trees, and thus functional languages are a natural fit for defining them parametrically.