Hacker News Reader

As soon as I see the JSX critique I roll my eyes. This has been around since reacts inception and it just doesn't hold any water for me. I remember interviewing with a company in 2019 that was still on Angular 1 because they didn't like JSX, and didn't want to learn typescript. It just "looked yucky" to them.

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.

I understand the instinctive reaction against JSX. I did a lot of Perl and PHP way back when, when it was super common to have bits of template sprinkled hither and thither with logic woven in here and there, and it made maintainability a nightmare. When the world moved on to dumb templates and embrace of MVC, it was a huge relief. JSX felt like a regression in that regard, but in practice, I think it ends up being pretty straightforward, in part due to the lack of any real flow control inside of it, and in part because of the convention of having small functional components which return a JSX tree, rather than bits of JSX just popping up everywhere here and there.

> JSX felt like a regression in that regard, but in practice, I think it ends up being pretty straightforward

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

You can definitely do JSX wrong. React doesn't do a whole lot to protect you from it, it's true. But, in a project which uses it well, I hate it a lot less than I once did.

> in ES-like pseudocode

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>
    );

Without the ternary operator:

    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>
      );
    };

If you allow the repeat of the 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>
        );
      }
    };

With a separate render function:

    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>
    );

Probably should have been more clear. It's not that the ternary operator is horrible when used judiciously in a small toy example, it's that it's difficult to parse with longer blocks of code or any complicated flow control. Consider the following very contrived example:

    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>
    );

Thanks for expanding! And do you see my other three refactorings similarly lacking?

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.

> Thanks for expanding! And do you see my other three refactorings similarly lacking?

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.

Sure, that's hard to read. So don't write it like that. Early returns; decompose it further; pull the `size` out of the todo data model and into a view configuration; etc.

I don't write it like that, but I wish I had better alternatives that weren't hard to read, one of which I described in considerable detail.

Yeah, this example highlights the weakness of conditional expressions in Javascript in general. JSX is expression-based, and so you end up in this situation. DSLs added on top of HTML can add something resembling the conditional statements that many are used to. Still, JSX needs the TC39 proposals for the do expression or pattern matching to pass to improve the situation.

> HTML's a tree. Function calls are a tree. They're similar in nature and they map cleanly to each other

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.