[lucideer]

> JSX' awkward attribute (re-)names

The attribute renaming is a React feature. JSX doesn't rename attributes. See here for example https://codepen.io/lucideer/pen/jOZvwVz?editors=0010

> only expressions in brackets but full function calls in loops (map)

Not sure what you mean here. Function calls are expressions - they work bare in brackets & also as method args (like the arg passed to the map method on an array prototype, which is called while "loop"-ing that array). This is all Javascript functionality, not really specific to JSX in any way?

[the_gipsy]

I stand corrected about JSX attribute renaming! However I still see it being applied in practice for 99% of JSX use cases.

The problem with "only expressions in brackets" is that then you can write code in the template, but it's massively different to regular code. Worst of both worlds: code in templates and weird subset of code.

[lucideer]

> you can write code in the template

If this is undesirable as a feature, then yes, JSX is not an appropriate choice. JSX is the furthest thing from logic-less templating. But that's a deliberate design decision.

> it's massively different to regular code

It's not. It's just regular code - there are no differences.

> weird subset of code

It's not weird. It's any JS expression. All JSX brackets are values, and JS statements don't have return values, so embedding a JS statement within a JSX value would serve no purpose. What would it do?

All statements in JS can be expressed as expressions directly (ternary/array methods) or indirectly (nested within a function expression), so there's no loss of functionality - it's not even really a subset in that sense.

[the_gipsy]

> It's not. It's just regular code - there are no differences.

> All statements in JS can be expressed as expressions directly (ternary/array methods) or indirectly (nested within a function expression), so there's no loss of functionality - it's not even really a subset in that sense.

Do you not see the contradiction?

[lucideer]

Let me phrase it in a slightly different way:

Vanilla javascript assignments can be any expression.

JSX assignments (the brackets) can be any expression.

There's no weirdness nor extra limitations to JSX assignments compared to normal vanilla JS. It works exactly the same.

If you think not being able to assign JS blocks is weird you're going to have to explain to me what this piece of JS code would do:

  const val = if (x < y) { func(); }

[the_gipsy]

You're just stating the difference between a statement and an expression. FYI, other languages (e.g. rust) have embraced the "everything is an expression" and it works extremely well, where JSX wouldn't be so awkward (in this aspect) and we could write something like:

    <div>{if (list?.length > 0) {
      list.map(e => {
        if (e.items.length) {
          <div>Excellent!</div>
        } else {
          <div>Not good.</div>
        }
      });
    } else {
      <div>Nothin to see.</div>
    }}</div>

Now, if you want to write this in actual JSX, you have to do this:

    <div>{(!!list && list.length) // awkward way of writing code
      ? list.map(e => {
          if (e.items?.length) { // normal way of writing code
            return <div>Excellent!</div>;
          } else {
            return <div>Not good.</div>;
          }
        })
      : <div>Nothin to see.</div>
    }</div>

Do you see the contradiction of being forced to use only expressions, only in some places? And this happens all the time. The most frequent thing we do in UI is rendering lists, so we use `.map` with "regular" code constantly, mixed with the awkward "expressions only" areas. Sure, the reason is that JavaScript is like that, but that doesn't make JSX any better.